Member Patterns -- the bikeshed

[Brian Goetz]

I would summarize your comments below as: Let's throw the entire model 
in the garbage, and replace it with something like Scala's "return an 
Optional<Tuple>" instead.

We've been discussing the model for several years; you've been asking 
(and waiting patiently) for "when are we going to talk about declaration 
syntax", and now that we're there, you want to throw it all out and 
start over?

We've discussed how strategies that rely on "ask the user to declare a 
record for every API point" feel clever for about five minutes, but 
start to feel old quickly.

The "carrier" concept in your examples seems to be just another way of 
reinventing multiple return -- with the added dis-bonus of being like 
but not quite the same as records.  We've been pretty clear that 
"multiple return" is not the design center here.

The use of ! for indicating totality is interesting, that's worth 
thinking about.



On 4/3/2024 6:21 AM, Remi Forax wrote:
> I think that by not starting from the deconstructor, the notion of 
> inverse methods make less sense.
> I think that the notion of carrier / carrier type is less disruptive 
> that the notion of member patterns.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240403/7e22618d/attachment-0001.htm>