@average-vr-56795: i like them, because i think it encourages meaningful, non-colliding variable names.

Which is them here? In each pair so you prefer the former or later? :)

...sorry. i guess i was thinking about what i thought was the underlying question.

i obviously like colonless initializers because coffeescript popularized then in a sense but mostly echoing stu’s thoughts here exactly. i also find it much, much easier to always use destructuring assignment so it’s clear when we’re using some variable (instead of having to hunt down for

<object>.<field>

) — i feel like it also encourages more precise clone()ing and helps to understand where you can split up fields of a struct e.g. into different structs, because if you find yourself using

, .. }

too often you may realize you can move some of those fields elsewhere

Mm, less sure about destructuring assignment... "Namespaces are great, let's do more of those"

that makes sense, i guess i was thinking of it as an extension of the reasons colonless initializers can be nice. if there’s multiple variables of the same or similar type declared in a local scope that can be the opposite of helpful.

Interesting. I think the exact opposite for the same reasons. I dislike the colon-less construction, mostly because different scopes make sense to have different variable names, and I find "because a struct's field has this name" is a bad reason for a variable name in another scope...

@average-vr-56795: i think your

fs_pool

example is a good one

Except the PosixFS has a pool which is obviously a pool for FS operations so the fs is redundant and repetitive?

yea, perhaps. my guess is that that is the exception rather than the rule

I dunno, I feel like it's the same thing as destructing; in general I want things in the function doing the constructing to be a qualified with something which represents the thing they're constructing, but that qualifier is redundant within the struct itself...

i do not expect that folks will create local variables purely for the purposes of using the shorthand in an initializer

I find "because a struct's field has this name" is a bad reason for a variable name in another scope...

i think i understand/agree with the idea behind this, but my point of view was that the causality would flow the other way, that the variable would be named that way because the struct field was named that way -- this encourages struct field naming which is appropriate to use in destructuring let statements. this is also coming from my tendency to make pretty granular structs/enums so that there are more distinct names available. i agree that i don't see

let MyStruct { field_name , ... } = arg;

in the engine source much, and i can see that obviously

if let

and

match

introducing a new scope makes it easier to use field name destructing. (

let

should introduce a new scope too, imo, but it doesn't)