Augmentations allowing static and instance members with the same name. about language

[jakemac53]

Should we just allow this generally, even within a regular class declaration?

The main reason I would push for "no" as the answer here is it seems very weird if augmentations allow you to do something that can't otherwise be done.

Hopefully, nobody ever does this though because it is highly confusing. But, it isn't any worse than having extension methods which collide with instance methods (which I have seen before, fwiw, and it cost me several hours of debugging a null safety migration which changed the static type of a declaration which altered which method was called).

[lrhn]

Should we just allow this generally, even within a regular class declaration?

IMO, yes.
If someone wants to do it, they can use extensions for the instance member today, static extensions for the static member soon enough, and maybe augmentations too, unless we make sure to disallow it. Might as well allow them to write it directly, without the overhead and risk of not having the extension imported.

(My elevator pitch summary of #1711: Generally allowed, applies to all static-allowing namespaces. Constructors and statics still conflict. If both static and instance member declared in the same scope, the name is considered "conflicted" in that lexical scope, just like conflicting imports - only error if referenced by unqualified name. All other accesses are unambiguous about being static or instance.)

What it would allow is something like:

class Color {
  static const black = Color(0, 0, 0);
  static const red = Color(255, 0, 0);
  static const green = Color(0, 255, 0);
  static const blue = Color(0, 0, 255);
  // ...
  static const white = Color(255, 255, 255);

  final int red, green, blue;
  const Color(this.red, this.green, this.blue);

  String toString() => "#${_toHex2(this.red)}${_toHex2(this.green)}${_toHex2(this.blue)}"; // `this.` needed
}

[jakemac53]

Good point that true static methods don't have the same issues as extension methods since you have to go explicitly through the type anyways as soon as you are outside the lexical scope. SGTM

[jakemac53]

For posterity, I remembered the exact situation with extension methods which caused me a problem previously.

There was a variable who's type was originally dynamic, so it was just doing an instance member call. As a part of the migration I changed something so that it had a better type, which was a super type of the actual (runtime) type. There was an extension member on that type, lets call the member x. But, the actual (runtime) type of the object also had a member x. Before the better type, it called the instance member, and afterwords it called the extension member. Quite the edge cases really, and doesn't apply to this situation.

[jakemac53]

I do worry that specifying this is allowed only for augmentations might break some backends which assume this isn't possible. I am not opposed to it in principle though.

[lrhn]

If we don't allow it in general, we should also not allow it with augmentations. That means explicitly saying that it's an error for a fully augmented class/etc. declaration to contain two declarations with the same base name unless:

• One is a constructor and the other is an instance member.
• One is a setter and the other a getter, and either both are static members or both are instance member.

(Base or augementing declarations must also not contain a member or type parameter with the same base name as the class, other than the unnamed constructor, or a member with the same base name as a type parameter. That can be checked locally since the declaration must repeat the class name and type parameter names. Or we can check that post-augmentation too. It's probably easier to do everything at once.)

[jakemac53]

That sounds fine to me (and we can later loosen it if we generally allow it)