Closed tesselode closed 2 months ago
nor do I think it could conflict with any caller-defined types.
Unfortunately, that's not true; for example, even without this PR, the following code fails to compile because the generated type shadows the type defined by the caller:
/// Sneaky choice of name
#[derive(Exhaust)]
struct ExhaustFooIter;
/// Errors because macro-generated `ExhaustFooIter` hides the intended field type
#[derive(Exhaust)]
struct Foo(ExhaustFooIter);
That said, there's room for improvement in making the namespace occupied by the macro consistent and documented, rather than ad-hoc and only hoping that underscores help. Or, I think the macro could scan the input code for conflicting identifies and rename its own types to avoid shadowing anything mentioned (though other macros appearing in the code could defeat that strategy).
I've prepared PR #46 as what I think is a more complete solution (which does still make the names camel case, but also makes them all use the same prefix scheme). @tesselode What do you think of it as an alternative to this PR?
that looks fine to me!
Fixes #44.
Since the types are private as of 0.2.0, I don't think this is a breaking change, nor do I think it could conflict with any caller-defined types.