Collect developer feedback about the ergonomics of `#{ }`/`#[ ]` (vs alternatives `@[ ]`/`@{ }` or `{| }`/`[| ]`)

[littledan]

Notice by @rricard: This issue is now only open to discuss the following alternatives: #{ }/#[ ], @{ }/@[ ], {| |}/[| |] or {| }/[| ]

---

Original issue text:

Most people I've talked to are pretty positive about @const in two ways:

• Since it applies deeply on the data structure, it's not too wordy to have these extra letters at the beginning. And a terser syntax (like #{ } / #[ ]) might be too cryptic and confusing.
• The name @const makes sense, since it's just like declaring a variable const, but it goes deeply through the data structure.

It'd be good to continue collecting feedback to understand if these intuitions are widely shared.

[rricard]

For now it does not seem to bug people I showed that to but we should try to get more feedback surely

[robpalme]

How would @const interact with decorators?

[rricard]

That's a good question, I should address that in the proposal text

[silverwind]

I don't think it's a good idea to overload the const word, either via a const operator or @const. Why not use a new word like immutable <varname> = <expression> that acts just like var, let and const?

[arxpoetica]

I agree about not overloading const. Need a new word.

[rricard]

Ok so here is what we've seen so far:

• @const - Pro: does not clash with existing syntax - Con: confusion about decorators
• const - Pro (to me): looks conceptually the same as c++ const pointer and const value type duality - Con: confusable with the existing const
• immutable - Pro: it's new it does not clash with existing - Con: it adds a new keyword is not necessary (using const in declaration and expression is differenciable)
• using the #{}/#[] syntax - Pro: make it clear we manipulate an expression here - Con: might be confusing, especially with private fields/methods

[rricard]

I honestly do have a personal preference with const but if there is a strong rejection of it, I'm fine to discuss the other options.

[zenflow]

I don't think it's a good idea to overload the const word, either via a const operator or @const

I agree with this. This is one of the first issues I found with the proposal. It shouldn't be hard to pick a new keyword that doesn't imply equality with the existing semantics of const (an association which seems false to me).

I think immutable would be the perfect keyword (actually I would even change this in the name of this feature, since I didn't know what proposal-const-value-types could be until I read "immutable" in the description) but it's a bit long for a keyword.. not sure if that matters. immut? sealed? frozen?

I would even personally prefer #{} syntax to using the const keyword, but as @littledan said above, it's a bit cryptic, and would be hard to google.

[zenflow]

Con: it adds a new keyword is not necessary (using const in declaration and expression is differenciable)

It may not be necessary for compilers to parse the code properly, but I think it would be helpful to make things clear to developers.

To draw a parallel: the let keyword was not "necessary".. we could have reused the if keyword, and statements like if foo = 3 would have been compiled correctly, but it's not optimal for developers for obvious reasons.

[vweevers]

A new keyword would help in conversation (casual or educational):

• "Could you help me with a bug? I've got this constant value.."
• "A deeply constant value or a constant variable"?

Versus "I've got this immutable value".

[rricard]

That makes sense, I'll talk with my co-authors and see what we should do!

[getify]

I am deeply, deeply troubled by the conflation of const here.

Speaking as a frequent teacher of these exact topics (const declarations vs immutable data structures), I can confidently say that most learners will not find something like const obj = const { a: 1, b: 2 }; intuitive, but will on the contrary be even more confused and unlikely to understand the differences.

The claims in the README that const x and const { .. } are obviously distinct / orthogonal do not track at all with my experience.

[rricard]

This is completely relevant and I think I can definitely put aside my affinity to what C++ would do (as a matter of fact const const in C++ is a pain to teach) so let's find a replacement!