-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Implicit coercion of Type
to Identifier
doesn't work
#55424
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
Comments
cc @scheglov @johnniwinther this feature would be nice for the stateful widget case (or in general when you want to generate a new class, and run macros on it which want to introspect on the original class). It would be nice to prioritize it somewhat highly (but behind anything json macro related), to unblock experiments in this area for flutter. |
Oh, I thought we supported just Identifier, but it looks like not (and they aren't in the spec either). For this case, a TypeAnnotationArgument would work too though. @goderbauer can you try that, using Or, you could just do |
Well, the specification says:
|
There is a complication with identifiers. At least in the analyzer. This is related to the moment when we instantiate macros. We do this right after parsing a file, so all we have is unresolved AST. And without types built and resolved, we don't know if We could Note, that people asked to arguments that are references to functions as well. |
The macro does not see any details of the Identifier, so what I would do is create an opaque Identifier, which gets its true information filled in after the types phase? Technically though, it is possible that a regular declaration could be added in the declarations phase, which shadows the identifier for the type.... |
And of course, it also isn't clear what the identifier should look like in the augmentation code from the first phase (what should the compiler say when asked to resolve the identifier to a URI by the augmentation library code?) |
I tried both |
What make me worry is using What to do if (after the types phase) it turned out to be a type literal, is an open question. AFAIK in the analyzer we don't rewrite @goderbauer Yes, currently the analyzer complains about any use of an identifier as an argument. We are trying to decide what should be done with such identifiers. |
This should be obsolete with dart-lang/language#3728 which will replace coercion with introspection. |
@davidmorgan For my own understanding: Does this mean instead of @Foo(String)
class Bar { } we should be doing @Foo("String")
class Bar { } and then resolve the string to the |
There isn't actually a concrete proposal yet, but you should still be able to have an API like |
Thanks for the clarification. Is dart-lang/language#3728 the tracking issue for that or is there a better one I can link to? |
dart-lang/language#3847 is the one you want :) |
I am experimenting with macros and ran into the following issue:
My macro definiton:
When applying this macro to a class, e.g.
the analyze is unhappy with this:
My understanding is that the
Type
should be automatically be converted toIdentifier
.The text was updated successfully, but these errors were encountered: