[Java/JVM] @:strict/@:meta doesn't support using annotations as arguments

[TheDrawingCoder-Gamer]

Certain java annotation args require using other annotations, but haxe doesn't not allow this at the moment. Equivalent java code: @Foo(@Bar("baz")) Haxe code (doesn't work) @:meta(Foo(@:meta(Bar("baz")))) My current workaround just throws haxe out the window for anything that requires annotations and doing a dual stage build.

[Simn]

Metadata cannot exist by itself, it always has to annotate something. That's why your example doesn't parse because just the metadata is not a valid expression. I don't know if there's a solution for this and I don't think I want to mess with this much. There have been ideas related to typed metadata floating around for a while, but nobody ever sat down to think this through properly.

[TheDrawingCoder-Gamer]

Yes, but this is strictly about java annotations, which this works with. If you can make a magic function that generates the annotation that's fine.

[TheDrawingCoder-Gamer]

Maybe in the java module or the java.Lib class?

[Simn]

This is mostly a syntactic problem. Before we can do anything this has to be expressed in a way that is valid Haxe syntax. IMO it should still be handled via metadata because it is declarative in nature, but I'm not sure how exactly to map it...

[TheDrawingCoder-Gamer]

I don't really know. This feels like something that would be better fit to a HXP, because adding support for metadata as expressions is a really big deal. I just want to write my stuff in haxe :sob:

[Simn]

I don't want to use metadata as standalone expression, I'm saying we need a different way to express this. Maybe something like @:meta($Foo($Bar("baz"))) which should be valid.

[TheDrawingCoder-Gamer]

I can see that, and that makes more sense. Of course this is a new syntax feature exclusively for java/cs annotations.

[Simn]

Sure but so is @:meta, although I'm seeing that it also does something in the SWF-generator. But yes, we should determine the common denominator for all affected targets and then find a syntax that is sufficient to express everything. I suppose that was also the idea behind how @:meta works, but that approach is fundamentally flawed.

[TheDrawingCoder-Gamer]

I think the $Foo syntax is fine as it has a different syntax from regular, non-declarative functions and metadata.

[TheDrawingCoder-Gamer]

Has anything happened here? I'm coming back to using haxe for mods but this time under C#, and I don't think @:meta has been fixed

[Simn]

I'm still not sure about the syntax so I was hoping someone would make a better suggestion...

[TheDrawingCoder-Gamer]

Merging #10749 will close this

[EliteMasterEric]

10749 corrected the issue with untyped metadata, but @:strict still doesn't have a proper syntax to work with as far as I'm aware.

Is syntax still an issue here?

[Simn]

At this point I think that @:strict needs its own mini-typer that deals with all the syntax. The original implementation tries to use the real Haxe typer, but it's quite awkward to manage. For meta inside meta we'll need some inner recursion to handle all the cases. I'll see what I can do.

[EliteMasterEric]

At this point I think that @:strict needs its own mini-typer that deals with all the syntax. The original implementation tries to use the real Haxe typer, but it's quite awkward to manage. For meta inside meta we'll need some inner recursion to handle all the cases. I'll see what I can do.

Curious on if there's been any investigation into the rewrites required for this to work and how those are progressing.

[EliteMasterEric]

Bumping this, as I am trying to work with the Mixin library, and create a set of macros to make it easier to use them.

Attempting to use @:meta doesn't seem to link the classes for the resulting annotations properly, and @:strict explicitly forbids the required syntax (for example, @Inject takes an array of Java classes as an argument).