[Wildcard Variables] Feature Specification

[kallentu]

Issue for tracking that the feature spec is in progress or is complete.

The working spec is located here: https://github.com/dart-lang/language/blob/main/working/wildcards/feature-specification.md

@eernstg @munificent Can we confirm that the spec is basically complete? Is there anything else we need to discuss or decide on?

Work Items

• [Wildcard Variables][spec] Allow super._? language#3792
• [Wildcard Variables][spec] Treat all multiple underscores as wildcards? language#3793

[lrhn]

I just checked, and the icky thing I disagree with is disallowing super._.

We should allow it.
If it breaks the current desugaring specification of super parameters, then define super._ as introducing a fresh name instead of no name.

[eernstg]

I added the rule that super._ is an error because the desugaring will turn it into code that doesn't work (or code that does something completely different! - if _ in super(..., _, ...) will now denote a static or top-level declaration).

We could try to enable super._ by introducing an implicit renaming step that makes it possible for the superinitializer to denote this parameter. However, I think that would be an anomaly, and it is yet another exception to remember while coding.

So I'd prefer that we keep super._ as an error. Developers may then do the rename themselves. First case, it's in the same library:

// Current code. Breaks because `super._` will be an error.

class A {
  final int _;
  A(this._);
}

class B extends A {
  B(super._);
}

// Migrated code. No problem, no rename lints, no code outside this library can know.

class A {
  final int __;
  A(this.__);
}

class B extends A {
  B(super.__);
}

Other approaches can be used as well, of course. For example, the initializing formal in A could be turned into a normal parameter with some other name (say, __), such that the name of the instance variable wouldn't have to change, and we'd have A(int __) : _ = __;.

In the other case, where A and B are declared in two distinct libraries, we might introduce a lint message which would then need to be ignored:

class OtherB extends A {
  OtherB(super._);
}

class OtherB extends A {
  // ignore: matching_super_parameters
  OtherB(super.__);
}

In general, we will continue to allow developers to use _ as the name of some declarations. But I do not think we should bend over backwards to make it convenient to do so, at the expense of the consistency and comprehensibility of these parts of the language.

[lrhn]

I think we should allow super._ because I don't expect users to expect an exception, so it not working is a surprising exception to them.
If the author doesn't use the name of a positional super.x parameter, it's reasonable to assume that changing it to super._ is fine. After all, they can change it to super.y or super._arglebargle without any problem.

The reasoning that the specification uses the name is meaningless to the user. Can't it just not do that? Yes, yes it can. It's an accident of specification that the name is used, not anything inherent to the feature. It used to be a safe assumption that the name given to the parameter would still be in scope and refer to the same value at the point of the super constructor invocation, so the specification chose to specify the meaning as a desugaring to an invocation that references the parameter variable. That's no longer safe if we allow super._, but that shouldn't break the wildcard feature by disallowing a meaningful use, it just means that the specification of super parameters shouldn't make that assumption any more, and should be rewritten to work anyway.

We can make it work. How we do that is up to us, it shouldn't matter to the user that we wrote a specification for super parameters that wasn't forward compatible. That's our problem, and we should solve it, and allow super._.

[lrhn]

Another thought: Maybe we should treat all of __, ___ etc. as non-binding declarations too. It's not necessary, but I'm not sure I'd want someone to write __ as a name, just to not have it be non-binding, and still not give the thing a real name.

It's a little iffy, because then they should probably work the same in patterns too. And that's an unrelated breaking change.
(Still think it would be prettier.)

[munificent]

Another thought: Maybe we should treat all of __, ___ etc. as non-binding declarations too. It's not necessary, but I'm not sure I'd want someone to write __ as a name, just to not have it be non-binding, and still not give the thing a real name.

I considered that when I was first writing the proposal. You're point about it being inconsistent with patterns is, I think, a good one.

Also, we ultimately want to get to a world where people don't use __, ___, etc. So I think scoping wildcards to only be a single _ helps us go in that direction.

[kallentu]

Moved all discussions to their own issues. Easier to keep track :)

• [Wildcard Variables][spec] Allow super._? language#3792
• [Wildcard Variables][spec] Treat all multiple underscores as wildcards? language#3793