> "vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside.
How would this interact with the orphan rule? Wouldnt this mean the vocabulary traits would not have default or std library type implementations and would have to be wrapped in newtypes, defeating the purpose of having them for inter-crate exchange? I guess you could wire types explicitly with Into/From in user code. Are there any traits unimplemented in std now that these vocab traits would look like?
Re:Rust's 2017 Roadmap
by steveklabnik on Monday February 06, 2017 @06:33PM
(#13585388)
It helps with the orphan rule, as everyone would be importing the trait from std. From/Into are the same kind of traits. That is, the idea is that the rand crate would implement std::rand::Random, and so would some rand2 crate, and then I could write my own crate saying
fn random<R: std::rand::Random>(r: R)
and it would work with either one. No need for newtypes.I also might be missing something.
stdlib or in a crate for just the trait similar to log?
Re:Rust's 2017 Roadmap
by steveklabnik on Monday February 06, 2017 @06:28PM
(#13585353)
The parent is worried about 2.0, so that would imply in stdlib. No reason it couldn't be done as a crate just for the trait as well, but that at least leaves the possibility of a 2.0 open.
Not worried about 2.0.
Rand is at version 0.3 and stagnating. I'm worried about 0.3, 0.4, 0.5. Those that have rand as a public dependency cannot release 1.0 now, if they do, they need to release 2.0 when rand goes to 0.4 and so on.
"vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside.