[swift-evolution] [Discussion] Simplifying case syntax
Erica Sadun
erica at ericasadun.com
Tue Feb 28 14:17:39 CST 2017
> On Feb 28, 2017, at 12:19 PM, Matthew Johnson <matthew at anandabits.com> 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: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--
More information about the swift-evolution
mailing list