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.

[programmerjake]

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.

+1

I've been writing Rust for around 2 years now, and I never realized until now that drop was in the prelude -- I've always imported std::mem and used it as mem::drop(x). I don't recall ever seeing any code that uses it from the prelude.

[kornelski]

I'm regularly using drop from the prelude. It's very handy in async/await code where it's efficient and sometimes required to explicitly drop stuff before .await points.

[jhpratt]

@kornelski Is it something that most people use on a regular basis though? Other items in the prelude are used all the time by a lot of people.

[kornelski]

I use drop more often than try_from, for example. Probably because one is in the prelude, and the other isn't :)

I think removal of drop is an unnecessary churn:

• it has legitimate use-cases, like unlocking mutexes early, explicitly disconnecting mpsc senders, removing ballast from Futures.
• it's been used in code examples and the Rust Book.
• it's harmless, and it's not deprecated.
• dropping it would not improve anyone's Rust experience. There's no other drop function waiting to be used instead.

[Lokathor]

Error I'm sure breaks someone.

HashMap and HashSet probably break people as well.

[matklad]

Error I'm sure breaks someone. HashMap and HashSet probably break people as well.

As far as my understanding goes, adding types (as opposed to traits) to the prelude is not a breaking change. Prelude is shadowed by glob and explicit imports.

[scottmcm]

We talked about this in the lang team triage meeting today, in the context of rust-lang/lang-team#44.

The zulip thread (https://rust-lang.zulipchat.com/#narrow/stream/243200-t-lang.2Fmajor-changes/topic/MCP.3A.20per-edition.20preludes.20lang-team.2344/near/205701158) raised a question about how this is going to interact with name resolution in macros. We'd appreciate it if someone in the community could take a deep dive into the best way to resolve this specific question, as overall we'd probably like to do this.

[jhpratt]

Here's something that I just ran across: the only Debug imported is the derive, not the trait. I don't know if it needs to be edition-specific, butt it's something worth considering.

[matklad]

Adding Debug or Display to prelude will probably break some code, as they both share the fmt name, so this might add new ambiguities to method selection.

[danielhenrymantilla]

Across this lengthy thread in internals we can see that there are many people, myself included, who would like for bool to feature a .not() method that would always be in scope, so as to allow whomever prefers it that way to replace the prefix sigil ! with a postfix annotation, which is a pattern seemingly considered idiomatically/ergonomically superior (c.f. .await and suggestions for .match), and that's without mentioning stuff like !matches!. Obviously one can emulate that by having Not in scope, but the ergonomic hit of having to use a trait for something as simple as condition negation is then a big source of churn.

I thus suggest that the Not trait be also added to the next edition prelude (2021), since it may be simpler than adding an inherent .not() method 🙂

[est31]

cc #82217

[djc]

I've posted an initial take on an RFC for this: rust-lang/rfcs#3090. Please comment there.

[m-ou-se]

This has been implemented and is shipping in Rust 1.56 as part of Rust 2021.