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.