Ultimately, I'd like to have both:
- irrefutable matching:
- refutable matching:
One is a syntactic convenience for selection only, the other
for selection plus structural tests (actually: behavioral interface
tests, see below). Both have their uses.
This suggests having pattern syntax modifiers for indicating
refutable or irrefutable matching, and deciding which of the
two is likely to be more common (and thus to be the default
for patterns without modifiers).
Assuming, for this discussion, that '!' marks a refutable pattern,
while unmarked patterns remain irrefutable by default, we could
then keep
let {foo: myFoo} = {a:0,b:1};
as a shorthand for
let myFoo = {a:0,b:1}.foo;
while writing
let !{foo: myFoo} = {a:0,b:1};
..
as a shorthand for something like
switch ({a:0,b:1}) {
match {foo: myFoo}:
..
break;
default:
throw "match failure"
}
This kind of interface check with early failure is a weaker, but still
useful, form of the compile-time check in module imports. Compare
let !{foo: myFoo} = {a:0,b:1};
and
import {foo: myFoo} from ToModule({a:0,b:1}); // is this permitted?
If the latter is not permitted, the former at least allows for declarative
interface specification and early failure, if the export interface of a
dynamic module does not match the intended import interface.
If the latter is permitted, why not allow a similar check for non-Module
objects, using let '!pattern = object'?
That would also make pattern semantics more uniform, instead
of selecting refutable or irrefutable semantics based on context
(switch/match or other).
Apart from module imports and pattern matching, there is another
question/relation to consider:
- refutable "structure" matches are a form of type guards,
which are another strawman for ES.future; if type guards
are not limited to switch/match statements, why should
refutable patterns be?
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
