zenparsing
Inconsistency with a variable list that does not allow initialization
It's clearly an intentional choice, but I wanted to file an issue to discuss the inconsistency that currently everywhere in the language you can have a list of variable declarations, you can also initialize them at the same time (which allows for const semantics), however, this proposal does not allow them (to be fair, class fields doesn't allow for const fields either).
Inline initialization is a pretty important feature of the current class fields proposals (#27) so it'd be great to have more clarification on why the use cases it serves aren't needed here.
Inline initialization is a pretty important feature of the current class fields proposals (#27) so it'd be great to have more clarification on why the use cases it serves aren't needed here.
see https://github.com/zenparsing/js-classes-1.1/issues/26
In summary, initializers in instance variable declarations add very significant complexity and don't provide any capability that can't be achieved by initialization code that is placed within the constructor
imo, prohibiting initializers adds much more complexity for the user (spec complexity is much less important), by introducing an inconsistency with how var lists work (https://github.com/zenparsing/js-classes-1.1/issues/32#issuecomment-372464510)
an inconsistency with how var lists work
I agree with this observation but come to a different conclusion. We should not use var for this.
@erights
I agree with this observation but come to a different conclusion. We should not use var for this.
Even we use other keyword like hidden a, b, c, it won't stop programmers trying initialization form. They will think let/const/varall support list with initialization, why whateverkeyword not. So I don't think use a different keyword can really help for consistency in programmers' mind.
The keypoint is initializer support, not var or other keyword, not allow list or disallow.
And, I always think we could add initializer in the future if we really want it. What we need now is just a comprehensive syntax error message to appease programmers when they happen to try initialization form.
I've had a thought on a possible fix here:
- Why have the early private field/instance variable declaration at all?
- Why not allow privates (whatever we call them) to be declared (and initialised) in the constructor?
This would be closer to the status quo whilst adding the new feature and not needing a new keyword (you'd declare them in the constructor with this->name = value)
Unless there is an implementation based consideration for needing the early declaration?
