Rust Version Attribute, based on the Haskell model

internals ideas (deprecated)
1

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.
  • Redefine std as 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 std or alternatives can come along that do less things better, and everyone lives happily ever after. libposix/libwin32, libffi-helpers, a typesafe liblibliblibc, ICU bindings instead of String, libev/glib/Win32/whatever runtime, etc. I wouldn’t be surprised if some of these were already in the works.
2

How is

#![language="foo,bar,baz"]

different from feature-gates?

#![feature(foo)]  
#![feature(bar)] 
#![feature(baz)]
3

It is different, because a feature doesn’t define the syntax, in other words; they are orthogonal concepts.

4

I do not think this is the core team's intention.

IMHO, if Rust becomes a research language which is perpetually unstable like Haskell GHC, where every bug is fixed only on master, Rust will totally fail to take any market share from C++ and company.

Versioning may be reasonable, but don't do it expecting that!

5

There’s a recent blog post outlining the plan for stability and evolution here.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.