[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