This started out as a reply to this post, but got long enough that I felt it would be hijacking the topic.
I expect 1.0 will be the
K&R of Rust: support will be there for code that wasn’t updated for whatever reason, but nobody in their right mind will start a new project on it after we get better alternatives.
- There are Standards and Extensions. They’re well-defined and behave exactly the same on all compilers that support them. Current feature gates strive to be stabilized into proper Extensions.
- A Standard is simply the previous Standard enhanced by a set of Extensions.
- Selection happens with something like
#[language="1.0, foo, bar, baz"], with one Standard and a list of Extensions.
#[cfg(language="foo")]compiles items if the compiler supports the Extension.
#[language]can either be mandatory, or compilers default to the latest Standard they support. The tradeoff is less boilerplate for new projects vs always knowing how to build a crate. There’s not much difference once people start using extensions.
- Extensions may break compatibility with the Standard and with each other. I fully expect any number of things to fundamentally affect the language and the ecosystem: HKT, generic variadics, anonymous enums, exceptions, inheritance, consolidating non-
#[repr(C)]structs and tuple-struct-whatever-enums into something sane, etc. Their ergonomics are more important than compatibility. Compare C++ where the best practices are so ugly, Rust exists.
stdas internal to rustc and not prelude it in by default. The compiler folks can focus on bootstrapping without all the cruft, and we can either fork/Cargo
stdor alternatives can come along that do less things better, and everyone lives happily ever after.
libffi-helpers, a typesafe
liblibliblibc, ICU bindings instead of
glib/Win32/whatever runtime, etc. I wouldn’t be surprised if some of these were already in the works.