Summary
Introduce many re-exports to std to shorten overly verbose and repetitive path names.
Motivation
Paths in the standard library are currently structural over expressive; everything is organized into
modules, and items generally only have one path. The only exception to this is std::collections
,
which re-exports its collections at the module root, but nothing else in the standard library does
this.
This system results in very verbose and repetitive paths, such as std::vec::Vec
or
std::default::Default
. This is especially noticable for items with common names, such as
Error
(which often has to be renamed to StdError
to avoid repeating the long path) and in
macros, where the user has to use the full paths. Code like ::std::default::Default::default()
just obfuscates the actual intent of the code, and ::std::Default::default()
or even
::std::default()
(as implemented by default_free_fn
) would be much clearer.
This change will also greatly improve the readability of code when absolute paths are used; while
std::time::Instant
cannot be read in plain English ("the standard library's Instant in its time
module" is out of order and confusing), std::Instant
can ("the standard library's Instant").
Furthermore it will reduce the mental overhead of having to know the locations of items; instead of
having to remember whether Unpin
lives in std::pin
, std::marker
or std::ops
users will
simply be able to write std::Unpin
. This applies to many other types in the standard library too.
Guide-level explanation
Firstly, everything with obvious repetition in the path name, such as std::any::Any
,
std::future::Future
or std::rc::Rc
, will also be accessible from
the crate root - std::Any
, std::Future
or std::Rc
.
Secondly, everything in the prelude will be accessible there, including std::marker::Send
,
std::fmt::Debug
and std::convert::AsRef
as std::Send
, std::Debug
and std::AsRef
.
Finally anything that has implicit repetition in the path name (for example
std::collections::HashMap
, as there's no such thing as a HashMap
that's not a collection) will
be there too - std::HashMap
.
Reference-level explanation
The following items should be exported at the crate root of their appropriate crate:
core::any::Any
core::borrow::{Borrow, BorrowMut}
core::cell::{Cell, RefCell, UnsafeCell}
core::clone::Clone
core::cmp::{Eq, Ord, PartialEq, PartialOrd}
core::convert::{AsMut, AsRef, From, Into, TryFrom, TryInto}
core::default::{Default, default}
-
core::fmt::Debug
- Not
Display
as it is not in the prelude.
- Not
core::future::{Future, IntoFuture}
core::hash::{BuildHasherDefault, BuildHasher, Hash, Hasher}
core::hint::unreachable_unchecked
core::iter::{DoubleEndedIterator, ExactSizeIterator, Extend, FromIterator, FusedIterator, IntoIterator, Iterator}
core::marker::{PhantomData, PhantomPinned, Copy, Send, Sized, Sync, Unpin}
core::mem::{ManuallyDrop, drop, MaybeUninit}
core::num::NonZero*
core::ops::{Drop, FnMut, FnOnce}
core::option::{Option, Some, None}
core::panic::PanicInfo
core::pin::Pin
core::result::{Result, Ok, Err}
core::str::FromStr
core::sync::atomic::{self, Atomic*}
core::time::Duration
core::lazy::{Lazy, OnceCell}
alloc::borrow::ToOwned
alloc::boxed::Box
alloc::collections::{binary_heap, btree_map, btree_set, linked_list, vec_deque}
alloc::collections::{BinaryHeap, BTreeMap, BTreeSet, LinkedList, VecDeque}
alloc::rc::Rc
alloc::string::{String, ToString}
alloc::sync::Arc
alloc::vec::Vec
std::collections::{hash_map, hash_set, HashMap, HashSet}
std::error::Error
std::fs::{File, FileType, create_dir, create_dir_all, read_dir, remove_dir, remove_dir_all, remove_file}
std::path::{Path, PathBuf}
std::sync::{Condvar, Mutex, MutexGuard, RwLock, RwLockReadGuard, RwLockWriteGuard, mpsc}
std::time::{Instant, SystemTime, SystemTimeError, UNIX_EPOCH}
std::backtrace::{Backtrace, BacktraceStatus}
std::lazy::{SyncLazy, SyncOnceCell}
In order to reduce confusion none of the above re-exports will be inlined.
Drawbacks
- Perceived churn: This change could cause additional churn if users believe the old paths to be deprecated.
- Long crate root documentation: The
index.html
of the standard crates will become a lot longer. - Confusion about which path to use: Now that types are accessible from multiple places, confusion could arise about which path to use.
Rationale and alternatives
- Hide the documentation of the re-exports: This allows the
index.html
of standard crates to be shorter, but significantly reduces the accessibility of these exports, and will make it a quirk rather than a feature of the language. - Inline the documentation of the re-exports: This perhaps makes the items more accessible, but having multiple pages for the same item can cause confusion about whether they are the same thing or just look the same.
- Do nothing: There will be less confusion as to which path should be used for an item, but user code will have many more imports, and macros will have to write out long repetitive paths.
- Re-export a different set of items: This is always possible, the list above is not final.
Prior Art
- C++ has most of its types defined at the root of
std
, for examplestd::vector
.
This section is incomplete, please respond with more ideas.
Unresolved questions
- What changes should be made to the list above?
Future possibilities
None I can think of.