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 =
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 =
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.
On Feb 28, 2017, at 12:19 PM, Matthew Johnson <email@example.com> wrote: