soaks on lhs of assignment

[mark-hahn]

It would be nice if this ...

a = {}
# b not defined
a.b?.c = 1

did this ....

a.b = {}
a.b.c = 1

It is very intuitive, doesn't break anything, and matches soaks on rhs in terms of handling missing properties.

[jashkenas]

Check out Coco's autovivification.

[michaelficarra]

Yep, Coco's .@ would be the equivalent of what you're asking for.

I wouldn't mind seeing something similar in coffeescript, but I don't like that syntax. Just throwing out the first idea that came to mind, maybe a parametrised member access: a.({})b.c = 1 using your example. That allows arbitrary literals to be defaults, so a.(p)b.c would be equivalent to (a.b ?= p; a.b.c).

[satyr]

a.({})b.c = 1

Isn't (a.b or= {}).c = 1 satisfactory if that's acceptable?

[michaelficarra]

@satyr: You're right, I didn't even think of that.

[TrevorBurnham]

It is very intuitive, doesn't break anything

To the contrary, a.b?.c = 1 is currently a useful shorthand for a.b.c = 1 if a.b?.

I'm with Michael that autovivification would be nice, but I haven't seen a good syntax proposal yet.

[showell]

Autovivification--like its close cousin, destructuring assignment--is probably overly constrained by having to play nice syntactically with the overall language. I almost feel like CS should have an explicit mode for data-oriented code (where convenience of data transformations trumps all other concerns).

At the very least, it would be nice to explicitly move in and out of autovivification mode. For example, at the top of a method, you might want all code to autovivify without any strange syntax, but once you get into the main processing, you'd want CS to generate code that fails hard when fields are messing.

[michaelficarra]

I don't get it. What was lacking with @satyr's suggested (a.b ?= {}).c = 1 solution? There, it's a new object if it didn't exist previously. No new syntax necessary.

[showell]

The problem with "(a.b ?= {}).c = 1" is that the syntax obscures the main intent of the code: you want to assign 1 to a.b.c (with autovivification as a side effect). The (?={}) syntax is hardly light--six punctuation characters and two extra spaces. If CS allowed you express it something like ":autovivify a.b.c. = 1", it would be more terse in terms of tokens, more human readable, and easier to type correctly. It would also be easier to turn autovivification on and off as you refactor the "convenience" up the call stack (letting lower-level methods fail hard if they aren't properly initialized).

[michaelficarra]

Modal autovivification is a bad idea. If that's what you want, we should have compiler directives and macros.

[showell]

I am not defending autovification, but to the extent that folks are gonna do it anyway, I'd rather have to read ":autovivify a.b.c = 1" than "(a.b ?= {}).c = 1" in other people's code.

I firmly support compiler directives in CS, but my notion of a compiler directive might be different than yours.

[geraldalewis]

I personally don't mind (a.b ?= {}).c = 1 or (my preferred) (a.b or= {}).c = 1. I usually associate modes with diminished usability; not that there isn't a use-case -- just that they usually gloss over deeper issues, hamper discoverability, and impede forming a good mental model of what the code is doing.

I also think that ?= is a great example of sigils used effectively.

[showell]

I still haven't fully digested CS's mental model w/r/t destructuring assignment, existential assignment, and autovivification. The concepts don't seem to have an elegant unification under CS, but maybe they don't need to, or maybe they do, and I just don't get it yet. They seem like close cousins to me.

[fernandortdias]

Thank you, @vendethiel, for finding all related issues (actually, feature requests) and closing mine (really). Although this one is already closed for almost ten years already, I woud like to join and "refresh" the discussion mentioning that, for me, not having to declare a variable before it has a value assigned to it is a kind of a "autovivification", and if CS handles its variables this way, I see no reason for not behaving the same way for key-value pairs in objects, so no special compiler mode, directive or sintaxe should be needed to specify that autovivifaction is intended. For me, the absence of autovivification in CS signalled an inconsistent behaviour. At most, maybe turning off autovivification should be considered the exception, as it is the annotation of types on version 2.5.1. So, if @vendethiel or some of you guys enlisted as collaborators agree on my argument, maybe one of you would like to reopen this features request, or mine, or any one of the other related to them.