Syntax for handling nullable variables
nathggns opened this issue · comments
Hi guys.
Apple's Swift as a feature called "Optionals" that makes handling nullable variables a lot easier. While I don't expect an exact port of this feature (as Swift doesn't actually use a null value for nullable values, but instead it all works on top of their Optional enum) there are some syntax niceties that I think we could port. Specifically, their Optional chaining feature.
The syntax I would like is this:
// b is a maybe variable containing an object with a property of c with a type of number
let a = b?.c;which would equivalent to the flow code:
// b is a maybe variable containing an object with a property of c with a type of number
let a: ?number;
if (b != null) {
a = b.c;
}You could chain this almost infinitely.
// d.e is a ?number
let a = b?.c?.d?.e;which would be equivalent to the flow code
let a: ?number;
if (b != null && b.c != null && b.c.d != null) {
a = b.c.d.e;
}I apologise if this has been suggested before.
This would also hide the awkwardness of having to use == in this particular case from the user, which is worrying when we're suggesting that people for the most part use === to avoid awkward type casting.
This would be cool, I agree, but at this time flow doesn't actually do any source transformations.
If this syntax were an ES201X proposal with transpiler support, we would have to consider it. Until then, it's doubtful we will take it on.
If you want to move the issue forward, I think you should start with the esnext standardization process.
Source transformation/flow-specific syntax isn't totally off the table, but there's quite a bit of friction to that path.
Does that make sense?
That makes total sense. It's a bit of a catch 22 though because it's not going to be added to ESNext because it's a types feature, and this types tool won't add it because it's not in ESNext. Does that make sense?
I think there is a reasonable runtime interpretation, actually. Coffeescript has such a syntax without a type language, for example. In fact, I believe I read a strawman on the esdiscuss mailing list about this, and the feature was rejected due to desugaring edge cases or something like that.
In any event, I think we don't need to worry about the catch-22, but I wouldn't hold your breath for this to become a proposal either.
This could totally be an ESNext feature. Javascript may not be a typed language, but it does have null and undefined values. As such, a.b can often result in a error such as cannot read property b of undefined
A simple sugar could be to check that the value is not null or undefined for every question mark.
I wonder who I have to ask to help make this a proposal...
Someone has already proposed it for you. The real interesting discussion is on es-discuss: https://esdiscuss.org/topic/existential-operator-null-propagation-operator
Well that's good news!
Related news. I often use a helper function to do the same for me. Something like:
isObj(a, 'b.c.d')
Is there a way to tell flow that this does the null-check? because I still get flow errors when I use such a function. Some sort of type annotation perhaps that can let me give a hint to flow.
Closing, this is out of scope
Is this still out of scope now that it's a stage 1 proposal and implemented in Babel?