Would it be possible to generate and combine code from different macros invocations in one place? about language

[jakemac53]

There isn't a way to implicitly search all transitive libraries and generate code based on what you see.

This is generally just a bad thing to do for performance reasons. It means that a single macro will have O(n) time complexity where n is the total number of libraries in the application, and there would be a large constant multiplier to boot.

Worse than just the time to execute the macro, it will also have to re-run whenever any library changes, because it has an implicit dependency on every library in the program.

We could try to design an alternative way to do this, which is more "modular", but it is challenging to design the semantics of it, and we aren't looking into it in earnest at this time. Essentially though, you would want the @Route macro in this case to simply emit some piece of data, which is globally readable from some other macro. And that higher level macro which reads all the global data emitted by all the @Route macros would only re-run when that data changes (so only if a new @Route was added, or one was altered). And the individual @Route macros only re-ran if the library they are applied inside of changes (or possibly even more granular than that, but it might not be necessary).

For this to be supported today though, you need some explicit piece of code referencing all the relevant types, to help you generate the AppRoutes class, something like this:

@GenerateRoutes([HomeScreen, LoginScreen]) 
class AppRoutes {}

[jakemac53]

I am going to close this as not planned for now, as we don't currently have any concrete plan to support it.

[ChessMax]

As far as I understand, we don't need to depend on all libraries. All we need here is to have some kind of API method that could return all classes with metadata (in this case, Route). And then it seems it would be possible to generate the method.

@GenerateRoutes([HomeScreen, LoginScreen]) 
class AppRoutes {}

I thought about code like this. If there is no other way, even this code would be OK. But in case of many screen classes it's still not that the best option from user point of view. Macros should help us to get rid of boilerplate, but the code like this is exactly with what macros should've help.
It is nice that we would have macros at all, but they are seem so limited right now.
Nevertheless, thanks for your reply!

[jakemac53]

All we need here is to have some kind of API method that could return all classes with metadata (in this case, Route)

The problem is that API has to visit all libraries to give you an answer. It has to look at every class in every library, and check for matching metadata. A naive implementation ends up re-running the entire query across the entire program, any time any change to any library is made.

Yes, this could be specialized in some way, such that when a single library changed we know all the whole-app queries which were asked, run those queries only on that library, and compare the old results against the new results, and only re-run the macros whose queries were affected. But, this would be a lot of work to design and implement in any sort of general purpose manner, not to mention extra memory to hold onto these query results indefinitely, etc. It has to be very carefully thought out to work well.