0020-macro-sensitive-imports

[0b1kn00b]

Thinking about macro errors and how to have less of them.

[Simn]

I acknowledge the problem but I don't think this is the solution. Imports are just tools to simplify type paths, so whatever problem you can create with imports you can also create without them. As soon as you have one macro function in your file, there's a risk of running into the problems outlined here.

[0b1kn00b]

Look at it this way, right now it's set up so that the complexity needs be managed by the user of the library. I'm proposing that the complexity is handled by the author.

…

On Thu, 5 Oct 2023, 14:24 Simon Krajewski, ***@***.***> wrote: I acknowledge the problem but I don't think this is the solution. Imports are just tools to simplify type paths, so whatever problem you can create with imports you can also create without them. As soon as you have one macro function in your file, there's a risk of running into the problems outlined here. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA34CVIRYXCAGQIQX7LCSTX52RG3AVCNFSM6AAAAAA5UD2ZV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBYG44TANRSGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Simn]

I don't see how that argument (which I generally agree with) relates to the proposal. It's not like imports are inherited by the users of a library.

[kLabz]

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 mark are not the only way to trigger problems so your proposal doesn't fix much.

[nadako]

MyModule.hx vs MyModule.macro.hx is the safe way to separate macro and non macro code

Can confirm, this kind of fixed all my issues with macro module dependencies.