Remove :: prefix from derived implementation.

[azriel91]

This allows an in-scope re-exported shred crate to be used.

Closes #102

---

I'll test this in a larger project, give me a few days to get to it.

[torkleyy]

Can we do this conditionally based on the edition being used? I don't want to break compatibility yet.

[azriel91]

Hm, the changes were more of a "get the user to explicitly use shred" instead of a Rust 2018 change. Would you still like it to be behind a feature gate? (can't find a way to detect based on edition)

[torkleyy]

Hmm, that would make it a breaking change...

…

On Tue, Dec 11, 2018, 08:23 Azriel Hoh ***@***.*** wrote: Hm, the changes were more of a "get the user to explicitly use shred" instead of a Rust 2018 change. Would you still like it to be behind a feature gate? (can't find a way to detect based on edition) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#103 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWFFufu1XhnKUbfjY4m-AE5ACwWlB5JMks5u311kgaJpZM4ZFpBM> .

[torkleyy]

Another question is whether shred or the individual symbols should be used. For other macros the latter is the case by now.

[azriel91]

that would make it a breaking change

yeap, would mean shred-derive 0.6; shred itself doesn't change so can stay at 0.7.1

whether shred or the individual symbols should be used

Going by the other crates, I'd go with the individual symbols for consistency. Reminder for myself: even if shred was re-exported under a different name, you can still import it as shred.

[azriel91]

Pushed a change for the latter method, people would need to make sure shred::{ResourceId, Resources, SystemData} are in scope.

[torkleyy]

Thanks!
bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push