----- Original Message -----
> From: "Tagir Valeev" <amae...@gmail.com>
> To: "Brian Goetz" <brian.go...@oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Sent: Wednesday, January 26, 2022 4:50:05 AM
> Subject: Re: Positioning of guards (was: Reviewing feedback on patterns in 
> switch)

> Hello!
> 
> For the record: I like the current version with &&. It's short and
> easy to understand (as people already know what && means in Java). I
> see no reason in replacing it with `when`, which is more limiting.
> 
>> because of the potential confusion should we ever choose to support switch 
>> over
>> boolean
> 
> It looks like any boolean expression that is a potentially constant
> differs syntactically from the guarded pattern, so we can distinguish
> between guarded pattern with && and boolean expression on AST level
> without resolving the references. End users will unlikely use anything
> other than explicit 'true' and 'false' constants, so it will add some
> complexity to the compiler but does not add any problems to real users
> 
>> because the && did not stand out enough as turning a total pattern into a
>> partial one
> 
> I think it's a matter of taste and habit. I, for one, already get used
> to it. It signals about partiality much more, compared to a simple
> type pattern. Looking at `CharSequence cs`, you cannot say whether
> it's total or not if you don't know the type of the selector
> expression. However, looking at `CharSequence cs && cs.length() > 0`
> you are completely sure it's not total. So if we need a clear signal
> to tell total and partial patterns apart, we have much bigger problems
> with type patterns.
> 
>> Guarded patterns are never total
> Except when guard is a constant expression that evaluates to `true`:
> 
> void test(Object obj) {
>    switch (obj) { // compiles
>        case Object s && true -> System.out.println(s);
>    }
> }

I think we should separate the two ideas in Brian's mail,
one is should we allow a guard inside a pattern ? and the other is what is the 
syntax for a guard ?

My position is that we should only allow guard in a switch, not as pattern.

And i see no problem to use "&&" instead of "when", as Tagir, i'm kind of used 
to it too.

regards,
Rémi

> 
> On Wed, Jan 26, 2022 at 2:49 AM Brian Goetz <brian.go...@oracle.com> wrote:
>>
>> > 2.  Positioning of guards
>>
>> We received several forms of feedback over the form and placement of guarded
>> patterns.  Recall that we define a guarded pattern to be `P && g`, where P 
>> is a
>> pattern and g is a boolean expression.  Guarded patterns are never total.  
>> Note
>> that we had a choice of the guard being part of the pattern, or being part of
>> the `case` label; the current status chooses the former.  (Part of our
>> reasoning was that there might be other partial pattern contexts coming, and 
>> we
>> didn’t want to solve this problem each time. (For instanceof, it makes no
>> difference.) )
>>
>> I am prepared to reconsider the association of the guard with the pattern, 
>> and
>> instead treat it as part of the case.  This is expressively weaker but may 
>> have
>> other advantages.
>>
>> Additionally, people objected to the use of &&, not necessarily because
>> “keywords are better”, but because of the potential confusion should we ever
>> choose to support switch over boolean, and because the && did not stand out
>> enough as turning a total pattern into a partial one.  What the alternative
>> looks like is something like:
>>
>>     switch (x) {
>>         case Foo(var x, var y)
>>             when x == y -> A;
>>         case Foo(var x, var y) -> B;
>>     }
>>
>> Here, `when` (bike shed to be painted separately) is a qualifier on the case,
>> not the pattern.  A total pattern with a `when` is considered a partial case.
>> This simplifies patterns, and moves the complexity of guards into switch,
>> where arguably it belongs.
>>
>> The loss of expressiveness is in not allowing nested patterns like:
>>
>>     P(Q && guard)
>>
>> and instead having to move the guard to after the matching construct.  Some
>> users recoiled at seeing guards inside pattern invocations; it seemed to some
>> like mixing two things that should stay separate.  (For unrolling a nested
>> pattern, `case P(Q)` where Q is not total unrolls to `case Pvar alpha) when
> > alpha instanceof Q`.)

Reply via email to