Priorities after 1.0

[nikomatsakis]

What is expected timing for associated constants and const functions? They are big and mostly implemented changes, but they will not land without serious attention from someone in the core team.

I’ve rebased eddyb’s const fn branch. I need to get that PR up. And I have to rebase again. I plan to take over quantheory’s associated constants branch as well.

[yigal100]

Community feedback is very important but we also should remember what Ford said: “If I had asked people what they wanted, they would have said faster horses.”

Some things on the list above I wish will not happen even though they get a lot of community support such as the ? operator. This is just hard coding a specific pattern by popular demand in lieu of a more general and more orthogonal design that would be possible if for example we get HKTs (already on the list!) and get something similar to Haskell’s do notation in the future.

I also agree that it is better to improve the tooling as first priority and allow for such more general designs more time to mature.

[engstad]

As a systems programmer, I am afraid that most all of these goals are not very interesting. The biggest hurdle for this kind of programming is related to how weak bit-level manipulation is in Rust as when compared to C/C++. Rust may be fairly well suited to compete with C++ on an application level, but for kernel work, console games and embedded systems, it has a long way to go.

I would love to see work on making good and unobtrusive syntax for bit-fields and also to make sure that the core libraries are organized in such a fashion that makes it easy to incorporate Rust into such projects.

[tikue]

Can you elaborate with a specific example of what you’d like to see?

[engstad]

tikue: Here’s a challenge for you. Try to write a disassembler for the x86 instruction set in Rust. If you try, you would quickly understand how dealing with bit-fields in Rust is painful.

[kornel]

For me Rust currently has two deal-breakers:

1. The hidden Drop flag. It makes C interoperability fragile and crashy (currently it’s really bad. Code that worked pre-1.0 crashes without warning). Having to choose between memory layout control or safety ruins a lot of Rust’s appeal for me.

2. Poor support for arrays. Everything nice in Rust is implemented as generics, and arrays don’t work with the rest of the language.

   The trait AnythingYouWantedToDo is not implemented for type [_; 16]

[tikue]

tikue: Here’s a challenge for you. Try to write a disassembler for the x86 instruction set in Rust. If you try, you would quickly understand how dealing with bit-fields in Rust is painful.

I’m not sure if you think I was being combative, but I was just asking for a more concrete suggestion, because I don’t understand from your post what the pain point is, exactly. I don’t think I should have to write an x86 disassembler to understand the problem you’d like solved.

[iopq]

Can you spare us the challenge and just suggest something?

[engstad]

tikue: Sure, point taken.

The issue is that when you are working with bit-fields, which you typically do when working directly with hard-ware, that it takes too much code in order to do something which should be very simple.

Since Rust doesn’t allow you to name individual bits in a type, it means that you have to either have to design a macro-system or you would have to use the very unsafe code like:

port.set_bits((port.get_bits() & !(3 << 5)) | new_value);

If bits could be specified (as you can with byte-values) in a struct, this would be:

port.field = new_value;

As you can imagine, if 50% of your code-base is all about setting these bits then you have a major source of errors.

[kornel]

I think it’d be great if rustc could dump a complete AST in some format (like JSON) that can be consumed externally (i.e. without having to write a Rust program against ever-changing unstable internal rustc API).

From this others could easily build code formatters, indexers, transpilers, FFI generators, documentation generators, etc.

[comex]

• I’d consider compiler performance the most impactful feature of anything mentioned in the list; to some people it doesn’t matter, but to people like me, it’s close to a deal-breaker. It also impacts tool support.
• SEME also looks particularly important, since it should improve ergonomics.

[bstrie]

Some things on the list above I wish will not happen even though they get a lot of community support such as the ? operator.

All changes will still require the RFC process. For any prioritized change without an accepted RFC, what is being prioritized is that the RFC be created as soon as possible so that it may be discussed.

[sanxiyn]

There already is rustc -Z ast-json (and noexpand variant), that part is easy. But instead of ever-changing rustc API, you get ever-changing JSON fields. The main problem is stablizing AST itself.

But you can certainly start prototyping all the tools you mentioned, right now.

[mdinger]

I think Rust next should at a minimum try to include 2-3 new nifty features because users love new features. On top of the improved infrastructure (improved build times or whatever), this should by default meet the suck less criteria.

I mean speed and such is always nice but when looking at release notes to decide if you should upgrade (especially if it’s already satisfactory), new features always tend to look cool and sparkly .

[EDIT] I’m not picky currently about which features get included though. A lot of things would be nice I’m sure.

[mikedilger]

How about extending std::process functionality re: stdio (i.e… setting file descriptors in the child & daemonizing)? It’s not listed in the library stabilization metabug. https://github.com/rust-lang/rfcs/issues/941

[hozumi]

I think the ability for Cargo to specify required Rust version is very important in long term. This feature have been requested many times[0] and require language level consideration, not third party tools’s hack. Millions of programmers hours have been poured into constructing and debugging rbenv, virtualenv and pyenv things. I hope rust will save that time.

[0] https://github.com/rust-lang/cargo/issues/1214

[gsingh93]

My vote:

1. Borrow checker improvements. Lexical borrows are really frustrating and leave a bad impression for newcomers.
2. Compile time improvements. The compile times from my small-ish applications are way too long, and I’ve given up trying to add improvements to rustc because of the build times.
3. Library APIs (specifically libraries outside of the standard library). I’d like to see the libraries that started in std, i.e. num, time, etc, get some love. Not only is there not really any improvement from the maintainers, but it’s hard to even suggest and discuss improvements for these crates. I remember I made multiple comments on an issue that I was willing to work on for one of these libraries (I just wanted the go ahead from the maintainers so it wouldn’t get rejected later on), but I got no response, so I just dropped it.

[tomjakubowski]

I definitely think that compilation times and compiler refactoring/cleanup should receive as much as attention as possible after 1.0. Consider that faster compile times and easier to understand internals means that work on the distribution, including for these other desired features and enhancements, will get done faster. It also means Bors can get through the queue and land changes more quickly.

[l0kod]

It would be a good thing to extend the function traits with something like FnAsync to be able to get safe reentrant functions.

[l0kod]

A Rust (exact) specification would be awesome with grammar tests and proof.