> On Feb 28, 2017, at 12:19 PM, Matthew Johnson <[email protected]> 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 > 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. -- 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
