Flow scoping

[Remi Forax]

It's basically what Swift does, you have a syntactic form for 
  if (x instanceof P(var y))
written
  if let y = (x as? P)?.y  
but it can not be inversed/negated (and you can not extract more than one variable easily).

so yes the question is where to draw the line.

I'm with Brian on this, given that in Java
  if (!(x instanceof P))
if a frequent idiom, i think it's better to support that idiom instead of saying we don't support it.

if we were developing a language from scratch, i would have agree with you Guy.

regards,
Rémi

----- Mail original -----
> De: "Guy Steele" <guy.steele at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 9 Janvier 2019 19:13:34
> Objet: Re: Flow scoping

>> On Jan 9, 2019, at 1:14 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> 
>>> Still, I believe that if you really care about making the structure of the code
>>> clear, then you would be well advised to (a) avoid inverting the sense of
>>> boolean tests, and (b) avoid relying on the fact that one arm of a conditional
>>> has a control transfer so  that you can “get away with” saving a level of
>>> horizontal indentation.
>> 
>> I think the clarity knife sometimes cuts in this direction, but sometimes in the
>> other direction.
>> 
>> If I have:
>> 
>>     if (x instanceof P(var y)) {
>>         // more than a page of code
>>     }
>>     else
>>         throw new FooException();
>> 
>> vs
>> 
>>     if (!(x instanceof P(var y)))
>>         throw new FooException();
>> 
>>     // the same page of code
>> 
>> In the latter case, i've checked all my preconditions up front, so it's more
>> obviously fail-fast.  Maintainers are less likely to forget the condition they
>> just tested a page ago, and readers are more able to build a mental model of
>> the invariants of the happy path for this method.  So I think it's not always
>> about "saving indentation"; in this case it's "get the precondition checks out
>> of the way, and set me up to do the work without further interruption.”
> 
> Sure—and in such a situation I might still prefer the first form, _or_ I might
> well choose to write instead
> 
>    if (!(x instanceof P))
>        throw new FooException();
> 
>    String y = ((P)x).yfield;
>    // the same page of code
> 
> and forego the slight advantage of pattern matching (perhaps relying on the
> compiler’s flow analysis to notice that the cast `(P)x` does not actually
> require a redundant run-time check), in order to make the scope of `y`
> crystal-clear.
> 
> There are stylistic tradeoffs here, and no one style is perfect.  If one style
> gets too squirrelly, the programmer can choose to use another.  Therefore we
> need not always go to extremes to salvage one specific style; that’s a
> meta-tradeoff language designers can choose to make.