Specification CL at https://dart-review.googlesource.com/c/sdk/+/81414.

Feature specification proposal in this PR.

Said feature specification landed as efdc2fa.

PR created for the feature specification: One rule needs to be discussed, and the right thing to do is to say explicitly that no conclusion has been reached yet, with respect to that particular rule.

I opened an issue for discussion of the question of using typedefs where classes are expected here.

Said PR now landed.

I think we need to update the spec to reflect the consensus on static method access.

Landed #116 for that.

Now that I actually want to use this feature (with JSON types, surprise surprise), I came across a problem: Where do I actually put the typedef?

In my Flutter app, I have this file structure:

|- lib
   |- data.dart -- exports everything in src/data
   |- src 
      |- data
         |- a.dart
         |- b.dart
         |- c.dart

If I want classes A, B, and C, each in their respective files, where should I put the Json alias? Seems like a lot of overhead to add a json_alias.dart file just for that. If I put it in each of the data files, then there will be conflicts. And I don't want to put it in any one data file, since Json isn't intrinsic to any specific class. If I put it in data.dart, then all importers can see it, but none of the data files can use it in their definitions!

@eernstg, thoughts? Are there any tests that happen to import aliases that I can pull inspiration from?

Seems like a lot of overhead to add a json_alias.dart file just for that.

I would probably do this.

Okay, thanks for the recommendation, I'll do that.

@Levi-Lesches
Now that I actually want to use this feature (with JSON types, surprise surprise), I came across a problem: Where do I actually put the typedef?

If you will be using more typedefs, a suggestion would be an encompassing root-level typedefs.dart; it doesn't need to be exported.

I have seen a lot of packages that would, in your scenario, have a src/data/common.dart solution, importing common into each a, b, and c.

Folks, this is all very interesting but Github bug comments are not the right space for it.

I tried this feature in IntelliJ dart plugin , like it still not support.

@fanthus, if you wish to report an issue with the IntelliJ plugin and non-function type aliases, please create an issue with 'area-intellij' and give more details.

Can it be possible to get the name of typedef instead the underlying runtimeType in future? Since it's just an alias, I think it might be feasible with an extra field for variables with typedefs.

typedef Meaning = int;

final Meaning life = 42;

void main() {
  print(life.runtimeType); // prints 'int'
  print(life.typedef); // prints 'Meaning'
}

Why I would need this?
Most of the time, I use runtimeType for labeling things in logs. But for typedefs it's not a case obviously. Example:

typedef SessionID = String;
final provider = Provider<SessionID>();

runtimeType is Provider<String> but there could be way to print Provider<SessionID> which is much more identifiable.
Also it would be very beneficial for writing something like golang style type-switch.

@esenmx The way you describe it, it is a new type rather than an alias. I guess the problem is that extends String does not work, but it is not an alias if you can switch on it.