Kevin Smith wrote:
I wonder: in what way does this design effectively decide the design
for an existential member operator (?.)?
Adding suffix-? to the pattern language still leaves open some design
decisions:
A. Whether to support suffix-? in expressions.
B. If not, whether to support ?. as a single lexeme for a saner
existential operator, with censored internal-Nil.
C. If so, then ? and . compose, so: whether to expose Nil in the language.
I agree that given "yes" to A, ?. must be two lexemes and operators, one
suffix-? and the other good ol' dot. But this does not imply "yes" to C.
I admit, it's cleaner and more CoffeeScript-friendly to say A="yes".
That still could leave C="no", since of course (same runtime semantics
as JS) CoffeeScript says "no" to C.
If it does decide the matter, then it seems like it might as well go
into ES6.
That's not true. It's still more work to spec ?. as well as refutable
destructuring for ES6. It requires an internal Nil (or Reference
variation as Allen suggested to me). It requires grammar hassling to
allow suffix-? in expressions.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
