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.
