Random Idea: A new prelude for Rust 2018?

[scottmcm]

Apparently adding TryFrom to the prelude broke some things, which made me think: Should we have a new prelude version for Rust 2018?

Good job whomever made the current prelude prelude::v1; we could do something like prelude::edition2018.

Things I don’t know yet:

• Is this compatible with what we’re allowed to do in the edition?
• Would writing a lint to warn about future breakage be feasible for this?
• If we did do this, what should get added to the prelude?
• Is this even important enough to bother with?

[rpjohnst]

It’s definitely an interesting idea, because the latest modules proposal involves adding dependency crates to the prelude as well. At the least, the compatibility lint questions overlap.

(I don’t have a strong opinion either way about anything else in particular changing in the prelude, except maybe… add HashMap?)

[petrochenkov]

Apparently adding TryFrom to the prelude broke some things

This is more about usual inference breakage from adding new methods/impls, rather than about prelude specifically.
Prelude additions may cause this only if traits are added into the prelude, but not other kinds of items.

[gnzlbg]

@petrochenkov could you explain which problems does adding a new trait to the prelude introduce ?

I’ve heard that it can be problematic a couple of times, but I don’t know much more than that. Is it just that it can make previously un-ambiguous code ambiguous if the trait methods have the same identifiers as other items in the users code?

[petrochenkov]

Is it just that it can make previously un-ambiguous code ambiguous

Yes, method call value.method() can become ambiguous if previously we had one trait Tr1 in scope with method method where typeof(value): Tr1, but with prelude addition we have another Tr2 in scope with method method where typeof(value): Tr2.

[leodasvacas]

On my wishlist there is Debug, Display and FromIterator. Maybe Write and Read?

[mark-i-m]

I don’t know if it’s too late, but the recent go versioning proposal proposes adding version names to paths: https://blog.golang.org/versioning-proposal

Maybe something like that might help with epoch transitions too?

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.