Is it possible to have a fully qualified Macro name or otherwise disambiguate a Macro name collision?

Let's say I have a Library called Things that includes a public definition for a macro named Foo:

@attached(member, names: named(isFoo))
public macro Foo() = #externalMacro(module: "ThingsMacros", type: "FooMacro")

In some project that imports Things and wants to use the Foo macro, there is already a type named "Foo":

// MyProject

import Things

// This project defines a type called Foo
protocol Foo { }

@Foo                     // <---  Error: Unknown attribute 'Foo'
struct Bar { }

Because my project already has a type called Foo, the macro from the Things library also called Foo doesn't seem to work here.

If I try to fully qualify the macro I see a different error:

@Things.Foo                     // <---  Error: No type named 'Foo' in module 'Things'
struct Bar { }

However if I remove or rename the Foo type in my project, the macro works fine:

// MyProject

import Things

// Rename Foo to Fee
protocol Fee { }

@Foo                     // <--- Now there are no issues, although referencing it as @Things.Foo still causes an error
struct Bar { }

I also tried:

// MyProject

// Disambiguate with specific import
import macro Things.Foo    // <---  various errors indicating that `import macro` not supported yet

So my question is if there are any strategies for disambiguating type name collisions between imported macro names and names of types defined in the module that wants to use the macro

5 Likes