[swift-evolution] [Discussion] Simplifying case syntax

[Matthew Johnson]

> On Mar 1, 2017, at 2:17 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
>> 
>> 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?

It has the same syntactic issue.  In fact, the issue is worse in design 1 because the `~=` operator is already a valid binary operator that can be used in normal expressions.  Introducing a special syntactic context where it has additional capabilities feels problematic to me.  I wish that wasn’t the case because I generally like the direction, but this seems like a pretty important consideration.

> 
>> 
>>> 
>>> -- E
>>> 
>>> 
>>>> 
>>>> href=3D"mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>" =
>>>> class=3D"">swift-evolution at swift.org <mailto:swift-evolution at swift.org></a><br =
>>>> class=3D"">https://lists.swift.org/mailman/listinfo/swift-evolution <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--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170301/4d806552/attachment.html>