We plan on not breaking code after Rust 1.0, except for gated features. That
said, we reserve the right to change things in potentially breaking ways if
type/memory unsoundness is discovered. We also might change small,
inconsequential things if we're reasonably sure nobody is relying on them--the
bar for this is high, however.
Libraries will follow a set of stability level guarantees that vary on a
module-by-module basis. Stability encompasses both API level stability and
semantic stability: if the semantics change in a way that is likely to break
code, we'll introduce a new API instead of modifying a stable one.
There will be plenty of new features added (e.g. unboxed closures, higher
kinded type parameters), and we discuss them a lot these days to make sure we
don't close them off.
We haven't discussed it, but I assume Rust 2.0 might break things. That will
presumably be a long way off though.
Patrick
"Gábor Lehel" <glaebho...@gmail.com> wrote:
>It would be helpful to know what the (rough) plan is for after 1.0. A
>series of 1.x releases and later 2.0, or just 2.0? At what kind of time
>scales? What kind of changes will be appropriate for each? (i.e.
>language
>features, bugfixes, compatibility breaks of various forms in various
>places)
>
>How is Rust going to feel about the prospect of backwards-incompatible
>changes after 1.0? Like C++: never ever break anything ever ever?
>
>
>On Mon, Dec 30, 2013 at 5:29 PM, Patrick Walton
><pcwal...@mozilla.com>wrote:
>
>> On 12/30/13 5:00 AM, Armin Ronacher wrote:
>>
>>> But there is so much more work needed. Not just because the
>language is
>>> lacking things that are needed, but because many users of the
>language
>>> are not sure yet how to use it.
>>>
>>
>> Documentation is independent of freezing the language definition.
>>
>>
>> The compiler and the standard library use widely different patterns
>and
>>> so do libraries written by other people.
>>>
>>
>> IMO, the compiler doesn't need to be updated to modern Rust before
>1.0.
>> (`javac` is still not updated to modern Java standards, for example.)
>The
>> standard library does, however.
>>
>>
>> There are half a dozen ways to
>>> deal with errors now, there are different patterns of how to deal
>with
>>> Options and Results.
>>>
>>
>> These need to be cleaned up before 1.0. Conditions in particular need
>to
>> be removed.
>>
>>
>> There are vastly different ways to design whole
>>> APIs, how to deal with the traits and so forth.
>>>
>>
>> We'll standardize on something before 1.0. The traits need to be
>> redesigned in general.
>>
>>
>> There are different
>>> patterns to interface with native libraries, different patterns to
>>> interface with task local data etc.
>>>
>>
>> Are you referencing RAII versus `with_foo` style methods? The latter
>are
>> deprecated and should be removed before 1.0.
>>
>>
>> The introduction of external iterators (which I found the most
>exciting
>>> change of the language) has shown a whole new area of shortcomings
>in
>>> the current feature set (lack decltype when returning composed
>iterators
>>> for instance,
>>>
>>
>> This is the first time I've heard of this as a missing feature, and
>I'm
>> opposed. This would make typechecking significantly more complex.
>>
>> non sendable closures etc.).
>>>
>>
>> Is `proc` not sufficient? We could prioritize adding unboxed
>closures, but
>> since they're backwards compatible as far as I know, I don't see a
>major
>> need to add them before 1.0.
>>
>>
>> Not only did it show
>>> shortcomings in lacking features, it also put some emphasis on new
>>> patterns that are not widely deployed in the stdlib yet.
>>>
>>
>> We need to add them before 1.0, but I personally don't see any major
>> missing language features that we absolutely need to add, except
>those that
>> are already on the roadmap.
>>
>>
>> I really hope there is left enough time to actually continue
>evolving
>>> the language and libraries before freezing anything. Especially now
>>> that the split into libnative and libgreen is happening it will be
>>> important to stay flexible for adjusting the design of the standard
>>> library so that we don't end up with two vastly different ways to do
>IO.
>>>
>>
>> We aren't going to freeze the entire standard library for all time
>with
>> 1.0. Instead there will be "stability levels" like node.js (something
>like
>> "frozen", "stabilizing", "unstable", "experimental"). I don't
>anticipate
>> that all of libstd will be frozen before 1.0. Some modules will, and
>other
>> modules will not.
>>
>>
>> As it stands right now, there
>>> are too many things that make Rust still frustrating because you
>program
>>> yourself into a corner.
>>>
>>
>> It'd be best to file specific issues here. I'm sympathetic to wanting
>to
>> adding more features if they're necessary, but none of the *specific*
>> things mentioned in this post seem like blockers to me.
>>
>> In general I understand the concern, but there are also a huge number
>of
>> people who just want the language to stabilize so that they can use
>it in
>> production. The window for relevance is finite and we've been
>designing the
>> language for a *long* time at this point.
>>
>> Patrick
>>
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
