Enum shorthands using a type alias and invoking a constructor

[eernstg]

Consider the following program, which assumes https://github.com/dart-lang/language/blob/main/working/3616%20-%20enum%20value%20shorthand/proposal-simple-lrhn.md:

class A<X> {
  final X x;
  A(this.x);
  AIntAlias get aInt => A(25);
}

typedef AIntAlias = A<int>;

void main() {
  AIntAlias _ = .new('Hello!').aInt;
}

The meaning of .new('Hello!').aInt is AIntAlias.new('Hello!').aInt, which is a compile-time error.

I think we would want to add a few words to the spec saying that the context type is subjected to a full alias expansion before we attempt to strip off the actual type arguments and re-compute them by inference.

@dart-lang/language-team, do you see any reason not to do this?

[lrhn]

The meaning of .new('Hello!').aInt should be A.new('Hello!').aInt (or equivalent to, in a way that avoids A being shadowed) .

The context type scheme is A<int>, which is the declared type of _.
The static namespace denoted by that context type scheme is the static namespace of the A declaration.

The context type scheme is a type scheme, which means it's a type-extended-with-_, so type aliases have necessarily already been expanded. Type aliases do not introduce types, just a way to denote a type, so there is no entity in the static type system that represents a type alias or instantiated type alias. That's entirely a syntactic concept, the syntactic type clause AIntAlias denotes the type A<int>, just like the type clause A<int>.

If the static type system can actually represent a type alias, I'll need to redefine "namespace denoted by context type scheme" to go through the alias, maybe the same way we do for accessing statics through an alias, but likely not exaclty, since I don't want to get the type arguments from the context type.

A type alias denotes the static namespace S if its RHS denotes the static namespace S.
(A type variable denotes no static namespace.)

But I don't think TypeAliasName<Type> is a type, so it's a category error to even ask whether a type scheme, can be a type alias.

We can add a note in the specification that context types introduced by types denoted using type aliases will not refer to the type alias, only to the denoted type, so that a type alias was involved has no effect on static shorthands.

[eernstg]

It's a good point that the context entity is a context type schema (which is a context type in the special case where _ doesn't occur), and hence it isn't syntax. In particular, there is no source code that directly denotes a context type schema.

Nevertheless, several specification documents do take care to call out type aliases explicitly (e.g., inference.md, normalization.md, upper-lower-bounds.md, and the language specification), indicating that type aliases have been fully expanded before the rules in subsequent sections of those documents are applied. So it probably wouldn't hurt to mention it.

In any case, we do agree that the original example should work as follows:

void main() {
  AIntAlias _ = A.new('Hello!').aInt;
}

which is what I wanted to clarify in the first place. I created #4186 to add a sentence to this effect.