Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow type arguments in class literals #11923

Closed
DartBot opened this issue Jul 19, 2013 · 14 comments
Closed

Allow type arguments in class literals #11923

DartBot opened this issue Jul 19, 2013 · 14 comments
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-duplicate Closed in favor of an existing report core-l type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Jul 19, 2013

This issue was originally filed by @seaneagan


We have class literals e.g. List, but they do not allow using generics, e.g. List<String>. One use case is issue #10407, being able to do:

expect(x, isA(List<String>));

instead of just:

expect(x, isA(List));

[Edit Mar 2021 eernstg: Closing this issue as a duplicate of dart-lang/language#123. This one is older indeed, but today dart-lang/language#123 is used to discuss this feature proposal.]

@iposva-google
Copy link
Contributor

Added Area-Language, Triaged labels.

@lrhn
Copy link
Member

lrhn commented Jul 20, 2013

Parsing could be harder in that case. What is:
  x < y > -1
?
It's silly code, because the Type object likely won't have a minus operator (yet? There has been talk about making static methods into instance methods on the type object).

@DartBot
Copy link
Author

DartBot commented Jul 22, 2013

This comment was originally written by @seaneagan


issue #1321 says chained comparisons will not be supported, and as noted there, in this case I think the associated syntax should not be allowed in the context of comparisons, since it leads to calling a relational operator on a boolean which doesn't makes sens. In which case:

x < y > -1

would not represent any comparisons, but rather calling the - operator on the class literal x<y> with argument 1.

@DartBot
Copy link
Author

DartBot commented Jul 24, 2013

This comment was originally written by @seaneagan


On second thought, that syntax is useful for DSLs, so it should be allowed. In which case, maybe the best we can do is:

to fix issue #2626 which would allow:

typedef StringList = List<String>;

...

expect(x, isA(StringList));

and then maybe sweeten it up a little bit, by allowing inline typedefs:

expect(x, isA(typedef List<String>));

@gbracha
Copy link
Contributor

gbracha commented Aug 25, 2014

On the one hand, one would like to have literals for all types. On the other hand, this is a rat hole (as anything related to generics invariably is).


Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

@gbracha
Copy link
Contributor

gbracha commented Aug 26, 2014

Issue #18758 has been merged into this issue.

@gbracha
Copy link
Contributor

gbracha commented Aug 26, 2014

Issue #18757 has been merged into this issue.

@gbracha
Copy link
Contributor

gbracha commented Aug 26, 2014

Issue #20027 has been merged into this issue.

@kevmoo
Copy link
Member

kevmoo commented May 8, 2015

There is a request for this feature in Angular: angular/angular#1691

@kevmoo
Copy link
Member

kevmoo commented May 8, 2015

Issue #23221 has been merged into this issue.

@DartBot DartBot added Type-Enhancement area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). labels May 8, 2015
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed priority-unassigned labels Feb 29, 2016
@munificent munificent changed the title class literals should allow generics Allow type arguments in class literals Dec 16, 2016
@rrousselGit
Copy link

I made a S/O question about this recently: https://stackoverflow.com/questions/52891537/how-to-get-generic-type

The answer provides a pretty good solution:

Type typeOf<T>() => T;

main() {
  Type type = typeOf<MyClass<int>>();
  print(type);
}

Kudos to Xavier

@lrhn lrhn added the core-l label Dec 6, 2018
@lrhn lrhn added this to Non-Breaking And Simple in Language Enhancement Categories Dec 14, 2018
@Levi-Lesches
Copy link

Any updates? I'm discussing adding macros on dart-lang/language#1482, and one of the big issues (I suppose for dart:mirrors as well) is that there's no way to specify "here's the type I want, make it a return type of this function". For example:

Macro getMacro() {
  final Type type = getType();  // some other function to return a type
  return Macro<type>();  // ERROR: The name 'type' isn't a type so it can't be used as a type argument. 
}

Among other uses.

@eernstg eernstg added the closed-duplicate Closed in favor of an existing report label Mar 8, 2021
@eernstg
Copy link
Member

eernstg commented Mar 8, 2021

@Levi-Lesches, I think your comment belongs somewhere else. This issue requests the ability to use a parameterized type (that is, a term of the form <typeName> <typeArguments>, e.g., List<int>) as an expression.

The language proposal to add this feature is dart-lang/language#123, and the standard workaround was shown by @rrousselGit here.

I'll close this issue because it is a language feature proposal, and they live in the language repository today, but if we were to transfer this issue to the language repository then it would be a duplicate of dart-lang/language#123.

@Levi-Lesches
Copy link

Ah okay I misunderstood. I realized anyway that by allowing a variable type as a generic, there could be massive problems with type-safety.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-duplicate Closed in favor of an existing report core-l type-enhancement A request for a change that isn't a bug
Projects
Language Enhancement Categories
Non-Breaking And Simple
Development

No branches or pull requests

8 participants