Rudy Ges

> So I propose that CODE additionally check for opening/closing curly braces {} and ignore their whole content. So for instance the following would be perfectly valid: > We could...

I have a lot too (and keep finding bugs, latest being https://github.com/HaxeFoundation/haxe/issues/8565 which should still apply to this RFC) but I'd prefer one of those two solutions to this RFC.

> We "only" need to decide for a minimal subset of syntax That's what @back2dos is proposing with a parser that can support a wide range of xml-ish possibilities, but...

> b) vs how much of a "precise" syntax will constraint the potential usages Do you have anything in mind? I genuinely cannot think of one.

`MyModule.hx` vs `MyModule.macro.hx` is the safe way to separate macro and non macro code, without `#if macro` rendering code hard to read. As Simn said, those imports you want to...

Why requiring the use of `Context.getDecoratorSubject()` instead of getting it as argument?

I don't know, really. All those switch + `case _: throw "Impossible";` etc seem pretty silly. We could easily have a different signature for body-less metadata for those not to...

I may be wrong but I remember reading something about the metadata function having some way to allow being used multiple times or not? That could potentially be used to...

> IMO we need separate syntax for this. I think @. has been proposed before. Also Simon proposed only allowing classes as metadata providers and disallowing "untyped" metadata starting with...

This can "easily" be implemented on user side, like it was done there: https://github.com/RealyUniqueName/Iterators