New pattern matching doc

[Elias N Vasylenko]

But if a failure to match throws a checked exception you _do_ have to 
specifically ask for it. You still get exhaustiveness checking by default, 
you will just see unintended assignment to a partial pattern surfaced as an 
uncaught exception.


There's no need to introduce new `try-match` syntax to opt into assignment 
to partial patterns, you can just lean on rules that users already 
understand. You ask for it simply by catching or throwing the potential 
exception.


    try {
      PartialPattern(var a) = blah;
    } catch (MatchFailException e) {
    }


Is that not sufficient?



On 16 January 2021 13:35:35 Brian Goetz <brian.goetz at oracle.com> wrote:

>> Hah, synchronicity! Yes, I was drafting an email with a suggestion for
>> something similar, although i used a __MATCH_OR_DIE expression form
>> that looked like a cast, and an unchecked exception.
>>
>> Did I just imagine it, or was there a suggestion for something like
>> this in the past?:
>>
>> var Point(var x, var y) = ...
>
> Close.  We have experimented with various forms of "imperative match".
> Our first attempt was something like:
>
> let P = e;
>
> where P had to be total.  This was later refined to something like
>
> let P = e
> else { ... }
>
> where the else block had to either throw, or assign to all the bindings
> in the pattern.
>
> We later started to feel that (a) `let` was unnecessarily fussy, and (b)
> casting it like a statement meant that we lost some other
> opportunities.  So we shifted towards something like
>
> P = e
>
> for suitably constrained patterns, on the observation that
>
> T t = e;
>
> which is currently a local variable assignment, could equally well be
> interpreted as matching the type pattern `T t` to the expression.  So we
> could retroactively reinterpret `P = e` (at least for type and
> deconstruction patterns) as an imperative match, rather than a
> declaration-with-initializer, if we want.  That's nice, but that kind of
> forecloses on the else clause.
>
> Regardless, the semantics here would be match-or-not, rather than
> match-or-die.  I think if you wanted match-or-die, you'd have to
> specifically ask for it somehow (such as a try- construct.)


Sent with Aqua Mail for Android
https://www.mobisystems.com/aqua-mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210116/1b606347/attachment.htm>