-
Notifications
You must be signed in to change notification settings - Fork 0
Post 1.0 Wishlist
HELLO INTERNET! THIS PAGE IS A WORK IN PROGRESS! PLEASE COME BACK WHEN IT'S DONE! UNTIL THEN, TAKE NOTHING AT FACE VALUE AND TRUST NOTHING WRITTEN HERE :)
Alternate title: Recognized pain points in Rust 1.0 that will be addressed backwards-compatibly in future releases
There's a misconception that 1.0 will be the last word for Rust. Rust 1.0 is ready for general use, but by no means going to stop moving forward. With the train release process, Rust will also continue to improve while still guaranteeing stability.
Let's use this page as a place to capture some of the issues we would like to see addressed post-1.0. Instead of waiting for the bloodthirsty internet to tear us to pieces, let's try to capture some informed feedback here, while reassuring people that this isn't the final state of the language and that open issues will get addressed. We can use this page to describe gaps and pain points we hit in the language today, as a way to help guide the planning and prioritization for the future of Rust.
Start by adding sections to focus the efforts. Try to stay topic-based rather than feature-based: instead of a section on "why I want higher-kinded types," have sections on issues with collections and issues with error-handling, where each can talk about how HKT could help.
Also this isn't going to become a blog post as-is or anything, don't fret about editing or perfect wording. For now this is just to collect material in a single place.
The primary reasons for this are largely that there are concepts that we want to be able to express in these traits that we can't really with the current type system. If we make them now, they'll be incompatible with the ideal design later.
That said, because Rust lets you define a new Trait and implement it for any type you want, you can easily make your own generic collection traits for any subset of behavior and collections you're interested in.
We're still diligently hacking away at how exactly this should work, and we can't implement an API that doesn't exist.
Still hackin'
Fixed-length arrays, denoted [T; n] currently enjoy some compiler magic to include an integer in their type. Unfortunately, nothing else can use this magic. So that means you can't have MyVecOnTheStack<T, n>. This needs static generic parameters which has been officially postponed for 1.0, as it would be fairly complex to implement, but should be backwards-compatible.
Also, even if you wanted to hardcode n, you also can't allow for partially initialized arrays either, because the current rules ensure the destructor of every field of a struct to be called. In the case of a [T; n], this means that every index will be destructed unconditionally. For types that don't actually have a destructor (like references and primitives), that's fine. For arbitrary types, that's Undefined Behaviour. This should be handled in some form by the ManuallyDrop proposal, which is unlikely to be merged for 1.0.
One day we'll have the tooling, though. Then we can do some great stuff here!
There is some experimental support for comparators in collect-rs, the experimental expansion-pack for libcollections, but it probably won't be ready for 1.0.
That said, for some simple use-cases you can make a new-type wrapper to change the implementation of Ord for that type.
The way iterators work makes this basically impossible. We need a different kind of iteration to support this, and it won't be ready for 1.0. collect-rs has some experimental support in the form of Cursors.