[swift-evolution] [Discussion] Simplifying case syntax

[Matthew Johnson]

Sent from my iPad

> On Feb 28, 2017, at 2:17 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> 
>> On Feb 28, 2017, at 12:19 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>>    charset=utf-8
>> 
>> I agree that the ambiguity created by moving `let` outside the local =
>> binding context is problematic.  I alway place `let` immediately =
>> alongside the binding for this reason. =20
>> 
>> In design 2 do you disallow matching a value using an existing name?  If =
>> so, how do users match values bound to an existing name?  Or is that =
>> just not possible?  I would oppose design 2 if it=E2=80=99s not =
>> possible.
> 
> It shadows, just like it currently does

In that case I oppose design 2.  If we're going to change this let's fix it and remove the ambiguity (from a reader's perspective when they don't know the rule).

> 
>> Both syntax designs you propose are very concise, but they look like an =
>> operator which can take any value with the appropriate type on the left =
>> hand side.  Unfortunately this isn=E2=80=99t the case (haha).  I think =
>> that is problematic.  Did you consider this?  If so, what is the =
>> rationale for this choice?
>> 
>> For example, a user might expect to be able to say:
>> 
>> // match is a boolean that is true if the pattern matched and fast =
>> otherwise
>> let match =3D .success(let value) ~=3D result
>> 
>> // we don=E2=80=99t know if `value` is bound here so we cannot allow the =
>> above to be valid code.
> 
> Swift doesn't allow the results of conditional binding to be used as straightforward 
> Booleans as they must be bound into a scope. `guard` cheats.

I understand that.  What I'm saying is that I can't think of any other binary operator in Swift whose result cannot be assigned to a name.  For that reason I am not convinced we should adopt the syntax you propose.  This *is not* a normal binary operator expression so it shouldn't look like one.

> 
> -- E
> 
> 
>> 
>> href=3D"mailto:swift-evolution at swift.org" =
>> class=3D"">swift-evolution at swift.org</a><br =
>> class=3D"">https://lists.swift.org/mailman/listinfo/swift-evolution<br =
>> class=3D""></div></blockquote></div><br =
>> class=3D""></div></div></div></body></html>=
>> 
>> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812--
>