Add a policy for inclusion in the prelude #66
Conversation
joshtriplett
added
T-libs-api
S-waiting-on-review
[DO NOT MERGE] Expand core's prelude with more types This adds some more types to the core prelude, to explore the [proposed prelude policy](rust-lang/std-dev-guide#66). Without any further context, types in the standard library are strongly associated with the standard library so they are good candidates for the prelude, assuming their name doesn't require a module to make sense of. As a bonus this avoids some of the repetition required for `cell::Cell`, `pin::Pin`, `atomic::Atomic*`, etc. Currently this includes some nightly types. These should be removed before this is merged.
|
It seems that there can be some issues with name resolution when adding types to the prelude: rust-lang/rust#125107 (comment) The crater run has |
[DO NOT MERGE] Expand core's prelude with more types This adds some more types to the core prelude, to explore the [proposed prelude policy](rust-lang/std-dev-guide#66). Without any further context, types in the standard library are strongly associated with the standard library so they are good candidates for the prelude, assuming their name doesn't require a module to make sense of. As a bonus this avoids some of the repetition required for `cell::Cell`, `pin::Pin`, `atomic::Atomic*`, etc. Currently this includes some nightly types. These should be removed before this is merged. In summary, this PR currently exports the following from the prelude: ```rust pub use core::cell::{Cell, LazyCell, OnceCell, RefCell, SyncUnsafeCell, UnsafeCell}; pub use core::ffi::{ c_char, c_double, c_float, c_int, c_long, c_longlong, c_ptrdiff_t, c_schar, c_short, c_size_t, c_ssize_t, c_str, c_uchar, c_uint, c_ulong, c_ulonglong, c_ushort, c_void, CStr, }; pub use core::io::{BorrowedBuf, BorrowedCursor}; pub use core::marker::{PhantomData, PhantomPinned}; pub use core::mem::{ManuallyDrop, MaybeUninit}; pub use core::net::{IpAddr, Ipv4Addr, Ipv6Addr, SocketAddr, SocketAddrV4, SocketAddrV6}; pub use core::num::{ NonZero, NonZeroI128, NonZeroI16, NonZeroI32, NonZeroI64, NonZeroI8, NonZeroIsize, NonZeroU128, NonZeroU16, NonZeroU32, NonZeroU64, NonZeroU8, NonZeroUsize, }; pub use core::panic::PanicInfo; pub use core::pin::Pin; pub use core::ptr::NonNull; pub use core::sync::atomic::{ AtomicBool, AtomicI16, AtomicI32, AtomicI64, AtomicI8, AtomicIsize, AtomicPtr, AtomicU16, AtomicU32, AtomicU64, AtomicU8, AtomicUsize, }; pub use core::time::Duration; pub use core::ops::ControlFlow; ``` UPDATE: There have so far been concerns raised about the following types: - `Cell` is maybe too generic a word to be in a prelude type - It is common for time libs to make their own `Duration` type so having it in the prelude may be confusing. This perhaps also suggests the design of std's `Duration` is not ideal but in any case that can't be changed at this point.
I think I agree with everything in this policy, but for me personally, I consider this is a necessary but sufficient criteria. In particular, in my opinion, I think there are costs to having a large prelude and I'm not sure this policy accounts for that at all. That is, as the prelude grows in size, I think our threshold for adding to it should also go up. That is, our standards should become higher. I don't know whether there is consensus on that point such that it can be added to the policy as written though. Perhaps just the "necessary but not sufficient" language would work. I'm not sure. |
|
@ChrisDenton wrote:
Fascinating. I think we should leave aside the issue of conflicts caused by naming a local variable the same as a unit struct (e.g. The issue of |
Thus far, we've added items to the prelude via ad-hoc policy, and we have not
necessarily had consensus on the underlying unwritten policy, only on
the application of that unwritten policy to individual prelude proposals.
This PR adds a proposed policy for including items into the prelude. This
policy also covers when we should add items to the common prelude versus an
edition-specific prelude.