Something to keep in mind - and this can be seen in the proposal name, “ECMAScript proposal: Types as Comments” - is that this isn’t adding types to JavaScript. It’s adding comments to JavaScript that is using the same syntax used by type checkers to specify data types. At runtime these types are ignored. So you could say
let x:number = "Hello, world!"
and still have valid JavaScript.
This means what you’re asking for @steve.mills would not be possible because at runtime, there is no type information to check. (You’d have better luck getting that behavior with a decorator extension.)
This also means that runtime types like this could never be added to JavaScript because doing so could “break the web” once anyone anywhere deployed code with an invalid type like the example above. The only way this could be made possible is if they added a new mode along the lines of “use strict” that enabled types providing an opt in (though the committees current attitude is “no new modes, ever”).
But that could be a good thing. Some languages are untyped. JavaScript is one of them, and it’s probably ok that it stays that way.
So, then, why do this at all? You can already use comments to add type annotations using JSDoc comments. And the proposal here is only for a subset of TS features to be added so it’s not like people can switch over from using TS to JS overnight. TS will continue to be TS and require a build step to transpile. All this is really doing is complicating the JS syntax making it harder to parse.
If I understand correctly this let {name = 'not given'} = obj
under the hood in will be:
if(obj.name === undefined) let name = 'not given'
else let name = obj.name
Considering that the colon : ‘operator’ in JS can be used as:
object intialiser {key: 'value'}
label loop1: for(let if of arr){}
ternary OR name ? name : undefined and now proposed as
type comment let x:number = "Hello, world!"
the context for which the colon was used would change the effect…
So why couldn’t let {name: string = 'not given'} = obj not be
if(obj.name === undefined || typeof(name)!== 'string') let name = 'not given'
else let name = obj.name
I understand that when you declare and store variables in Javascript as proposed let x:number = "Hello, world!" its not evaluated (or type evaluated) in any way and its not practical of performant to do that…
But with let {name = 'not given'} = obj… obj.name is being evaluated and another variable assigned as a pointer…
That’s just it, the colon doesn’t change anything. Its a comment. Its text completely ignored by JavaScript. It would have no effect on the behavior at runtime.
Could JavaScript be wired up to do something like this? Sure, but not with this proposal, and not with the prevailing idea that JavaScript remain untyped. This proposal sticks to that ideal (no types) by making these “types” comments only.
Going with the decorator approach, you could get exactly what you’re after with a slightly different syntax.
function asString(value) {
return typeof value === 'string' ? value : undefined
}
let obj = { name: 42 }
let { @asString name = 'not given' } = obj
console.log(name) // 'not given'
To be clear, that particular use is an “extension” and not something the current proposal would support out of the box. Given how long its been taking the current proposal to get off the ground (just for decorating classes and class members) who knows how long something like that would make it into the language, if at all.