> 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? > >> >> -- E >> >> >>> >>> href=3D"mailto:[email protected]"; = >>> class=3D"">[email protected]</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-- >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
