[External] : Re: Primitive type patterns

[John Rose]

On 26 Feb 2022, at 8:49, Brian Goetz wrote:

> …I think they mostly proceed from two places where we may continue 
> to disagree:
>
>  - You are generally much more inclined to say "if it might be null, 
> disallow it / throw eagerly" than I am.  In general, I prefer to let 
> the nulls flow until they hit a point where they can clearly flow no 
> further, rather than introduce null gates into the middle of 
> computations, because null gates are impediments to composition and 
> refactoring.

Now added to the lexicon:  “null gates”.

Here’s a slogan to go with it:  “No new null gates.”  It’s 
logically the same as “Let the nulls flow [until they really 
can’t]”.

>  - You are viewing pattern matching as the "new thing", and trying to 
> limit it to the cases where you're sure that users who are unfamiliar 
> with it (which is almost all of them) will have a good initial 
> experience.  (This is sort of a semantic analogue of Stroustrup's 
> rule.)  But I believe those limitations, in the long run, will lead 
> to a more complex language and a worse long-term experience.  I want 
> to optimize for where we are going, which is that there is one set of 
> rules for patterns people can reason about, even if they are a little 
> complicated-seeming at first, rather than an ever-growing bag of 
> individually "simple" restrictions.

I buy this argument too:  A rationalizing retcon for the existing 
assignment conversion rules will reduce the overall cost of adding 
patterns.  There might be a transient cost to attaching pattern 
conversions at the deepest level of the language, compared to making 
patterns into pure sugar bolted on the side.  But in the end I’d 
rather learn something that *does* have deep connections to the 
language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220226/4b1b8796/attachment.htm>