I guess that means the stuff I said about "only having to look in two
places" for null-handling was wrong; any static (declared) pattern could
be nullable. Which brings us back to the place that people didn't like
the last time around -- you have to scrutinize the implementations of
the patterns associated with all N cases to determine whether this
switch will take nulls or not.
On 1/9/2020 7:57 PM, John Rose wrote:
We haven’t yet moved on to library-defined patterns (“static
patterns”). To gaze a bit into the crystal ball: I think it’s
likely that those will provide a way to express T? using
a library API instead of a language primitive. We should
defer building out that last 1% of null support either
indefinitely, or until there is a way for libraries to define
their own kinds of patterns. In the latter case the cost
of adding a nullable pattern is likely to be lower than
the alternatives on the table, since library changes are
always cheaper than language changes.
