[swift-evolution] [Discussion] Simplifying case syntax

[Erica Sadun]

> On Mar 1, 2017, at 11:46 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>>> 
>>> 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).
> 

I don't mind dropping design 2. It was added to the conversation just as we stopped 
discussing this the first time. Was trying to pick up with all the conversation intact.


>> 
>>> 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.

How are you with design 1, my original design?

> 
>> 
>> -- 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--
>> 
>