> On Mar 1, 2017, at 2:17 PM, Erica Sadun <[email protected]> wrote: > >> >> On Mar 1, 2017, at 11:46 AM, Matthew Johnson <[email protected]> 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:[email protected] >>>> <mailto:[email protected]>" = >>>> class=3D"">[email protected] >>>> <mailto:[email protected]></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--
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
