2/ using an explicit type for a total type is a footgun because the semantics
will change if the hierarchy or the return type of a method switched upon
change.
Sorry, I think this argument is a pure red herring. I get why this is
one of those "scary the first time you see it" issues, but I think the
fear has been overblown to near-panic proportions. We've spent a lot of
time talking about it and, the more we talk, the less worried I am.
The conditions that have to combine for this to happen are already
individually rare:
- a hierarchy change, combined with
- enough use-site type inference that is not obvious what the type
dependencies are, combined with
- null actually being a member of the domain, combined with
- users not realizing null is a member of the domain.
Then, for it to actually be a problem, not only do all of the above have
to happen, but an unhandled null has to actually show up.
Even then, the severity of this case is low -- most likely, the NPE gets
moved from one place to another.
Even then, the remediation cost is trivial.
So by the above, this seems like a corner^7 case. How much are you
willing to distort the language to avoid it? I think the rational
answer is "none". And we've spilled a *lot* of ink on this issue -- to
the point where it has distracted us from much bigger concerns -- and
the only thing you've managed to convince me of is that, the more you
look at the issue, the more it becomes obvious that there is only one
reasonable choice here. So unless you have a powerful NEW argument
other than "something could change under subtle conditions, and then
something bad might happen", I think its time to move on.
I believe that before talking about 1/, we should determine if we should tackle
2/ or not.
I thought we had already established this, on both counts :)
To (2), I think the semantics proposed are right. The answer to "I can
write code that is brittle because it depends on the type hierarchy" is
not to forgo hierarchy analysis.
To (1), I think it treats something whose importance is "x" by spending
1000x worth of user-model complexity budget to arrive at less sensible
semantics.
If you have new arguments, I'm willing to hear them. But I don't think
there's any point in repeating the same arguments.
