Nullable switch

[John Rose]

On Aug 6, 2020, at 4:22 PM, forax at univ-mlv.fr wrote:
> 
> people are not compilers,

People do model compilers, and as Brian has shown, there is
already a workable concept (which Java programmers must
model) about totality.

> because you are mixing totality and nullability,

This is the “pick your poison” moment:  Often, cleanly factoring
out separate notations for separate concepts is the best move.

Not in this case.  The use cases (for totality and for null tolerance)
are very strongly correlated after (a process that takes months in
which) you run through all the various use cases and desired
symmetries and other principles that Brian alludes to.  It’s better
to mix here; using separate “unmixed" notations leads to two
strongly correlated channels of information that the poor
programmer will have to manage in tandem, even in cases
(common as Brian shows) where null policy isn’t even on the
user’s mental radar. *That’s* requiring the user to do the
compiler’s job.  Amber is about reducing ceremony; having
too many notations to make the same choices, and requiring
*both at the same time* is increasing ceremony.

> is the "case Comparable<?> c" accept null or not in the following code
> is not an easy question

But as Brian showed, it is the sort of question that programmers
have to be aware of:  Totality, like the DA/DU rules, is a concept
they need to know about to program correctly.

But the programmer doesn’t need to “be a compiler”; of course
the compiler does the detail work and tells the programmer
whether a given construct will fly or not.  And the programmer
learns by pattern matching, hunches, intuitions, which sorts
of statements and idioms are safe and which require greater
scrutiny.  If you look at the examples and use cases, and/or
try out some coding, I think you’ll find (as I did) that, because
the total patterns in a switch are *forced* by the compiler
to fall to the bottom, it’s *easy* to see at a glance which cases
are null-tolerant and which are null-hostile.

HTH

— John