Observation about nulls in type patterns
Brian Goetz
brian.goetz at oracle.com
Mon Jul 27 23:07:20 UTC 2020
> When you have a design issue where half of the planet think one way
> and half of the planet think the other way,
> the best is to have a kind of "mother may i" rule, basically, you ask
> the user to explicitly refine its intent.
But I don't think it is half and half. If you show people
switch (o) {
case Foo(var x, var y, var z): ...
}
and ask them "will this match all Foos", 999 out of 1000 will say "of
course, what else could it do?" THe idea that this might fail if z
happened to be null would not occur to anyone.
The semantics we've proposed stem from the above observation, plus the
requirement that `var` mean type inference, and not something more
subtle. If you are saying `var`, you should be able to substitute it
for the sensibly inferred type (if it is denotable) and get the same
semantics. This is not a random "gee, maybe this works."
Where things are troubling are not the pattern semantics, but how it
interacts with `switch`. So, if you think the status quo is
unacceptable, any "fix" needs to be closer to the switch interaction.
More information about the amber-spec-experts
mailing list