so i've mostly syntactic comments:
Augh! No! :)
- I was wondering if matches can be spelled instanceof ?
This would work if all we were ever going to do was type-test patterns.
But when it gets to destructuring patterns, structural patterns, regex
patterns, etc -- all reasonable possibilities in the future -- then
instanceof starts to feel more strained.
But we might consider a loosening of instanceof to accept a binding
variable *also*.
- the var pattern: i'm sure you have considered removing the 'var'
int eval(Node n) {
return exprswitch(n) {
case IntNode(i) -> i;
case NegNode(v) -> -eval(v);
...
};
}
but reject it because
- from the compiler perspective, you have to wait the typechecking pass
(or a pass just before) to know if a symbol 'v' is a parameter or variable
access.
Yes, we considered it. But the reason for preferring var here is not
necessarily just compiler complexity; it's that it's weird for
if (x matches Foo(y))
to be a _declaration_ for y. Java developers are not used to that.
Having the slightly more verbose
if (x matches Foo(int y))
or
if (x matches Foo(var y))
makes it more obvious that y is being declared, not used. This seems a
good tradeoff of clarity for verbosity.
- exhaustiveness,
if the class is sealed/closed, i think all data class should be declared
into the interface
sealed interface Node {
data class IntNode(int value) { }
data class NegNode(Node node) { }
...
}
It makes more clear the fact that you can not open the interface Node to add
a new subtype and you do not need to declare that each subtype implements the
sealed class.
This is definitely one of the contenders. Without branching out into
the design space of sealing too much -- the mention in the doc was
mostly intended to suggest that its on the table -- there's a spectrum
of flexibility for sealing (both at the language and VM level). The
simplest is that sealing means "nestmates only", as you suggest. Of the
candidates, I think this is probably the best choice at the language
level. It's on my list (but several entries down) to write up a more
detailed summary of our explorations here.
It also means that the real name of IntNode is now Node.IntNode (so you can
remove the Node suffix !), but you mostly don't care because when you use the
exprswitch, you're switching over a Node so the compiler can infer the right
name the same way the compiler infer the right name of an enum constant.
Like enums. (BTW, when we get to expression switches, we'll have to
tweak our treatment of exhaustiveness for enum switches.)
And more or less like Scala, the compiler can add a bunch of static factory
methods so instead of new Mode.IntNode(0), one can write Node.IntNode(0),
IntNode being the name of a factory method that creates an IntNode.
Possibly. Data classes are a whole separate feature, about which people
will have strong opinions... let's come back to that later.
