Adding conditional imports/parts with macros.

[lrhn]

Macros can add imports, and possibly also conditional imports (or they can import a library which has conditional exports).

If it's also possible to have conditional parts, which it should be because it's very useful for have your platform-specific code to have access to privates, then it becomes a question whether macros can add conditional part files (or sub-part-files at all).

The current model seems to be that macros are combined into a single augmentation file, really only because that makes the augmentations more easily readable while debugging.
It would also be possible for each macro to generate one new part file per phase, all appended at the end of the part-directive list, instead of just one file. That should give the same augmentation application order.

If a macro generated file can add a sub-part-file, at least one with no imports, then that can be flattened into a single macro generated file too, by just appending it at the end of the file. If the sub-part-file has imports, that flattening won't work, and if the sub-part-file declaration is conditional, then it definitely won't work.

In short:

• Should a macro be allowed to add part files to the generated code?
• (If a macro generates code with a macro annotation, could we make that work? If we can, would it then mean a new part file or not?)
• If yes to part files, how about configurable part files?

[jakemac53]

For now at least, I don't think it should be allowed. We have enough complexity already. Possibly in the future we evaluate it, if the need arises. For platform specific code my hope would be that most use cases can push the platform specific code to a shared library instead, which macro generated code uses.

[davidmorgan]

Agreed.

I think we can leave enough space in the host<->macro protocol that this is the kind of improvement we can make later.