Closed IsseW closed 9 months ago
Iirc this is commonly used via a re-export from
specs
so many users won't have theshred
crate in scope. I think it is worth giving this case some consideration.
Through specs you have specs::shred
to import in this case. Which I think will be a better thing to have to import than all of World
, SystemData
and ResourceId
. Which could collide with user code.
So maybe if there aren't leading any ::
this could work? I don't think there's a way to solve not having to import anything from specs without creating a seperate proc macro in specs.
Another alternative might be to stop re-exporting the macro in specs and require the user to depend on shred to get the macro.... although specs also re-exports shred so users could still try to use the macro without depending on specs...
I think having no leading ::
is a good compromise that improves the current state of things without regressions. This is the best approach for now IMO.
We could add an attribute to the macro for providing the path to shred (like serde
s crate attribute). This adds some complexity to the implementation though and would be more cumbersome to use especially in the common case of using the macro through specs. At that point a separate macro for specs may be ideal.
Removed leading ::
.
Iirc this is commonly used via a re-export from
specs
so many users won't have theshred
crate in scope. I think it is worth giving this case some consideration.