On Aug 6, 2020, at 4:22 PM, fo...@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
