Prohibit variable and identifier patterns from being named when or as, to simplify parsing.

[stereotype441]

This spec change reflects the discussion at dart-lang/sdk#52199 (comment).

Test cases are here: https://dart-review.googlesource.com/c/sdk/+/300320

[stereotype441]

@munificent I decided not to change the behaviour of when and as in constant patterns that are qualified names, or the behaviour of when in object patterns. Does that seem reasonable to you?

[munificent]

I would be very tempted to go farther and treat a pattern like an async function body where it establishes a region of code where when and as are treated as reserved words. That seems conceptually simpler to me than having them be contextual keywords only in certain specific contexts with a pattern but not in other contexts. I can't see much good coming from allowing you to use when or as as, say, the name of a type argument or the constant in a relational pattern.

There's also a process question here. Now that the proposal has essentially shipped, does it make sense to update the proposal itself, or should we treat this as a language change with a separate little proposal document for it? I suspect the latter will be easier for the implementers and people writing tests, but I could be wrong.

[stereotype441]

I would be very tempted to go farther and treat a pattern like an async function body where it establishes a region of code where when and as are treated as reserved words. That seems conceptually simpler to me than having them be contextual keywords only in certain specific contexts with a pattern but not in other contexts. I can't see much good coming from allowing you to use when or as as, say, the name of a type argument or the constant in a relational pattern.

Hmm, I definitely see some value in that from a standpoint of language evolution, since it helps move us toward a world where when and as really are reserved words. (I'm not sure if that's a goal of yours or not). Implementation-wise, though, it's a lot heavier of a change, because tokens are classified by the scanner, not the parser, and the scanner has no way of knowing when it's inside a pattern. So we would have to examine every part of the parser that's reachable from inside a pattern, and update its identifier-handling logic so that it rejects when and as in the appropriate circumstances. In practice this means we have to think about all pattern and expression parsing logic. And if we ever decide to relax the restriction that the expressions inside relational patterns must be constant, we would technically have to think about statement parsing logic too. That's a lot of parser rework to contemplate.

Implementation difficulty aside, I'm also not convinced it would be doing a service to users. If I'm unlucky enough to be the consumer of an API that contains a getter named when, I might have a legitimate reason to write an object pattern like Foo(when: var x?). Or if I'm switching on an enum and one of the enum values is named when, I might still want to be able to write case Foo.when:. And I might not really be in a good position to rename the code I depend on, so my only choice at that point is, don't use patterns. It doesn't seem like it would benefit anyone.

I think it's fine to stop people from naming things when or as at the declaration site, because that's where they're in a good position to choose another name. I could even get behind making a lint that stops people from naming things when or as even in code that doesn't specifically use patterns. But since when and as are still valid names for things that a pattern might want to refer to, I don't think we should stop people from referring to those things unless it's necessary to avoid parser ambiguities (and fortunately, it's not 😃)

There's also a process question here. Now that the proposal has essentially shipped, does it make sense to update the proposal itself, or should we treat this as a language change with a separate little proposal document for it? I suspect the latter will be easier for the implementers and people writing tests, but I could be wrong.

That's a really good question! I don't know how best to handle this.

[munificent]

Implementation difficulty aside, I'm also not convinced it would be doing a service to users. If I'm unlucky enough to be the consumer of an API that contains a getter named when, I might have a legitimate reason to write an object pattern like Foo(when: var x?). Or if I'm switching on an enum and one of the enum values is named when, I might still want to be able to write case Foo.when:. And I might not really be in a good position to rename the code I depend on, so my only choice at that point is, don't use patterns. It doesn't seem like it would benefit anyone.

Good point! OK, I'm sold on the approach in this PR.

That's a really good question! I don't know how best to handle this.

cc @dart-lang/dart-team

Maybe the larger team has thoughts.

[leafpetersen]

Maybe the larger team has thoughts.

For the scale of change we seem to be settling on, I'd just suggest landing it as a change to the existing spec (i.e. this PR).

[stereotype441]

Maybe the larger team has thoughts.

For the scale of change we seem to be settling on, I'd just suggest landing it as a change to the existing spec (i.e. this PR).

Works for me! I'll go ahead and land as is.

On a related note:

• Do you think this change should be language versioned? (My preference is no, since I think breakages will be minimal)
• Do you think we should go through the breaking change process for this? (Again my preference is no, for the same reasons)
• If I can get this change done quickly, do you think it would be worth trying to cherry-pick it into the stable release?

[leafpetersen]

On a related note:

• Do you think this change should be language versioned? (My preference is no, since I think breakages will be minimal)

No.

• Do you think we should go through the breaking change process for this? (Again my preference is no, for the same reasons)

No.

• If I can get this change done quickly, do you think it would be worth trying to cherry-pick it into the stable release?

Yes.

[dnfield]

How does this change affect https://pub.dev/documentation/mockito/latest/mockito/when.html?

[stereotype441]

How does this change affect https://pub.dev/documentation/mockito/latest/mockito/when.html?

With the narrower scope we agreed on in #3033 (comment), there's no effect on https://pub.dev/documentation/mockito/latest/mockito/when.html. The only things being prohibited here are:
The ability to declare a local variable named when through the use of a pattern, e.g.:

switch (...) {
  case var when:
    ...
}

The ability to assign to a local variable named when through the use of a pattern, e.g.:

String who, what, where, when, why, how; // This is ok
(who, what, where, when, why, how) = getQuestions(); // This isn't

And the ability to refer to lone (unprefixed) constants named when in a pattern or a switch, e.g.:

const when = 1;
switch (...) {
  case when:
    ...
}

None of which should interfere with the use of when in mockito.

[dnfield]

Thanks for the explanation!