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
···
On Feb 28, 2017, at 12:19 PM, Matthew Johnson <matthew@anandabits.com> 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).
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.
···
Sent from my iPad
On Feb 28, 2017, at 2:17 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Feb 28, 2017, at 12:19 PM, Matthew Johnson <matthew@anandabits.com> 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?
···
On Mar 1, 2017, at 11:46 AM, Matthew Johnson <matthew@anandabits.com> 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?
It has the same syntactic issue. In fact, the issue is worse in design 1 because the `~=` operator is already a valid binary operator that can be used in normal expressions. Introducing a special syntactic context where it has additional capabilities feels problematic to me. I wish that wasn’t the case because I generally like the direction, but this seems like a pretty important consideration.
···
On Mar 1, 2017, at 2:17 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Mar 1, 2017, at 11:46 AM, Matthew Johnson <matthew@anandabits.com> wrote: