Tracking issue for vNext edition prelude

[scottmcm]

There were plans to do this for the 2018 edition, but it never happened (#51418, #51434)

Things to consider:

• TryFrom/TryInto
• ???

---

Note 2020-04-19: Please limit suggestions here to things that would be breaking changes to do in the current prelude. Some prelude additions can happen without being a breaking change, and if you'd like to do one of those them just talk with libs about it -- it doesn't need to wait.

[jhpratt]

std::fmt::Display seems like a reasonable thing to include IMO.

[SimonSapin]

@jhpratt

• Why should it be added?

• Why this one and not other items from std::fmt? Display is rarely called directly but more often implemented. But to implement it you also need std::fmt::Formatter and <std::fmt::Result or std::fmt::Error>. But we already have std::result::Result in the prelude, and std::io::Error and std::error::Error that are not but share the exact same name and don’t seem to me less important than std::fmt::Error.

• If it’s added, why in an edition-specific prelude rather than for all editions? Edition-specific prelude are only discussed because adding TryFrom makes many existing calls to try_from methods of other traits ambiguous, breaking code that runs on Stable: Stabilize TryFrom / TryInto, and tweak impls for integers #49305 (comment)

[eaglgenes101]

Can I also suggest an ArrayIntoIterExt extension trait for the 2021 prelude?

AFAIK implementing IntoIterator for arrays is blocked on clashes with existing ecosystem implementations. This could be worked around starting with the 2021 edition by creating an extension trait for arrays which implements IntoIterator, and exposing it in the 2021 prelude.

A similar approach is currently to expose slice concatenation methods for technical reasons I still don't quite understand. So this approach, while unusual, is not completely unheard of.

[kornelski]

In addition to TryInto, I find adding quite frequently:

• Path and PathBuf
• HashMap and HashSet
• Arc and Mutex

I wouldn't add Display, because for implementing it, it also needs its formatter and result. It would be interesting to add std::fmt to the prelude, so that fmt::Formatter and fmt::Result work, but adding use std::fmt isn't too bad.

[SimonSapin]

If it’s added, why in an edition-specific prelude rather than for all editions? Edition-specific prelude are only discussed because adding TryFrom makes many existing calls to try_from methods of other traits ambiguous, breaking code that runs on Stable: #49305 (comment)

[SimonSapin]

@eaglgenes101 The problem with #25725 is not collision with methods of other traits from other crates, but collision of IntoInterator for [T; N] with itself for &[T; N] though auto-ref. Code that was previously valid (iterating &T by reference) changes meaning.

Having a new dedicated trait does not change the problem if the method is still named into_iter. And if it’s named something else, we’re back to the previous point that it doesn’t need to be edition-specific.

[mbrubeck]

I have previously suggested adding FromIterator to the prelude. Rationale here.

[joshtriplett]

I would love to see the following in an updated prelude:

• Error
• TryInfo and TryFrom
• Path and PathBuf
• Cow
• HashMap, HashSet, BTreeMap, BTreeSet
• File

I've based these on things I see imported heavily, and some greps for commonly imported bits of std in various projects.

I'm also tempted to request OsStr and OsString.

[SimonSapin]

@mbrubeck @joshtriplett Aside for TryInto and TryFrom (where we already know this is the case), do you expect that adding those to std::prelude::v1 for all editions would cause any breakage? If not, we shouldn’t make things edition-specific gratuitously and this is not the right thread to request additions.

[mbrubeck]

structopt, kuchiki, micromath, and clapme have trait methods that could conflict with FromIterator::from_iter.

Of these, clapme (which is not very widely used currently) definitely has conflicts: clapme::ClapMe is implemented for Vec and Option, which also implement FromIterator. The others could conflict in theory because of third-party impls, but I think such conflicts are unlikely in practice.

My best guess is that adding FromIterator to the prelude for all editions would break some existing code, but not a huge amount.

[jhpratt]

Here's one that may be slightly controversial — remove std::mem::drop from the prelude. I can't think of a single instance I've ever used it, and IMO having to explicitly import it would be clearer.