I don’t like this idea much. It conflates the naming of the parameters at the definition site to the local variables at the usage site.
This is so common already, I bet we name variables based on class definitions without giving it a second thought more often than we realize.
This is a refactor tool nightmare, and bugs waiting to happen.
Do you mean if variables changes names? Seems like a pretty straightforward, already well-supported refactor to me? Existing positional-based extraction seems much more problematic to me from both refactoring and local-usage-tied-to-class-definition standpoints.
In my 20 year software career I never needed a feature that extracts a bunch of variables into local scope. I think it can mostly be avoided by structuring your data better. If you like
verbosity that much, I am pretty sure you do not mind also typing the names twice.
What did the proposal say to indicate a propensity for verbosity? If anything, it is showing the exact opposite, no? We don’t always have control over the structure of data we’re working with, but even so, with “well-structured data” (which here means what, some limit on the number of fields?), you don’t always need every field of a class, and, again in my experience at least, it is pretty common to do things like val aField = aClass.aField ; val anotherField = aClass.anotherField... , i.e. name local vars the same as the class author has named it.
What are we optimizing for? So code can be written faster? You should not optimize for code writing speed (especially now with AI). One should optimize for code reading speed, which this barely improves (maybe even worsens due to larger cognitive load).
Yes, it is a syntactic sugar, and as with much syntactic sugar, its primary goal is to save keystrokes, and I think I actually improves readability over arbitrary numbers and placings of _, _, ... and having code with names repeated.
Sure, there will probably always be some cognitive load when getting accustomed to new syntax, I don’t think that’s a compelling enough reason on its own to avoid new things. Anyways, I don’t think the syntax proposed here takes a wild stretch of the imagination to understand what is going on.
Adding yet an other syntax for some minor character reduction gain would confuse more than it brings, imho.
I think much syntactic sugar can fall under this category, no? It might be confusing initially, but again, I really don’t think it is. And it is a common enough pattern in my experience (and apparently so in the experiences of developers of several other languages that have added support to allow this type of extraction), where I believe any difficulty of getting over this minor mental barrier is soon outweighed by the benefit.
We do not need every typescript / javascript stupidity in our language.
I agree there’s a lot javascript has gotten wrong, I’m not sure of the stupidity of clearer variable extraction though.
Either way, it would be an opt-in syntax, so if one is truly so opposed, there’d be nothing stopping anyone from retyping names and fields as much as they could want, right?