Language ergonomic/learnability improvements

[aturon]

Point of contact

@nikomatsakis @aturon @withoutboats

Overview

As part of the effort to lower Rust's learning curve, we are interested in pursuing a number of language improvements that will make Rust both nicer to use and easier to learn. The goal is to enhance productivity without sacrificing Rust's other core values. See the README for more details.

A kind of manifesto for this work was written up on the main blog.

Status

There are a lot of ideas in flight! The lang team has been focused on writing RFCs for the biggest changes; there are lots of opportunities to help either there, or with more narrow RFCs. If you are interested in the ideas listed below, please contact @aturon or others on the team to hook you up with a mentor for RFC writing!

The potential improvements are organized by broad areas of Rust:

Ownership/borrowing

RFCs

• Match ownership ergonomics (@nrc, @cramertj)
  • In FCP
• Non-lexical lifetimes
  • non-lexical lifetimes rfcs#2094
• Nested method calls
  • RFC: Enable nested method calls rfcs#2025

Sketches

• Allow owned values where references are expected (or: AsRef coercions) (@aturon)
  • Internals thread
  • Good mentored RFC!
• Auto-deref Copy types (@aturon)
  • Good mentored RFC!
• Lifetime elision improvements (@nikomatsakis, @aturon, @solson)
  • Internals thread
  • @aturon is currently taking point on this

Traits

RFCs

• Trait aliases (@withoutboats)
  • Accepted!
• impl Trait stabilization and expansion (@aturon)
  • Accepted!
• More impl Trait work, e.g. impl Trait in traits (@aturon, @cramertj, @eddyb, @withoutboats)
  • @cramertj is taking point
  • A dedicated repo
• Delegation of impls (@withoutboats)
  • Needs significant revisions; has stalled out
• Reduce repeated constraints when writing T: SomeTrait
  • Related to implied bounds
  • Closed in favor of Implied bounds rfcs#2089

Sketches

• Implied bounds (@nikomatsakis)
  • Implied bounds rfcs#2089
• dyn Trait syntax for trait objects (@nikomatsakis, @aturon)

Module and privacy system

Landed

• pub(restricted) is stable!

RFCs

• Allow extern crate to take a list (@withoutboats)

Sketches

• Possible module system improvements (@withoutboats, @aturon)
  • Follow up post and thread with further thinking
  • @withoutboats and @aturon have had a bunch of new ideas here; writeup coming soon.

Error handling

RFCs

• Extending ? to work with more types (@nikomatsakis)
  • Accepted!
• ? in main (@nikomatsakis)
  • Nearing FCP
• Coercions into Result when leaving a block (@scottmcm, @nikomatsakis, @aturon)
  • Good mentored RFC!
  • Posted as Ok wrapping: Improved support for writing code from an error handling mindset rfcs#2107 -- controversial; heading to close
  • Alternative RFC for just Try<Ok=()>: Add the () → Result<(), _> coercion rule, for removing Ok(()) everywhere. rfcs#2120

Primitive types/core traits

Sketches

• Allow string literals to somehow be used as String (@aturon)
  • See the internals thread
• Implicit widening on integer types (@aturon)
• Potentially deprecate PartialEq/PartialOrd (@aturon)
  • See this comment for a bit more detail and rationale.
• #[derive(Data)]
  • Possibly falls out of trait aliases

Type annotations/verbosity

RFCs

• Allow eliding types from const/static declarations (@schuster)

Sketches

• Eliding type name in match arms
• Eliminate need for the :: in foo::<u32>(blah), in at least the single-argument case
• Make coercions more applicable
  • E.g., to functions
  • E.g., better behavior in generic, trait-bounded contexts (this might be easy to do with Chalk)
• capture the full path in a closure, not just local variable
  • @nikomatsakis would be happy to mentor this!

FFI

Landed

• Unions
  • FCP period for stabilization is complete!

Other

RFCs

• Default struct field values
• Coroutines, supporting nice async/await syntax
  • RFC postponed, pending some open questions; see the summary and related internals thread
  • There's now a working implementation and async/await notation built on top; we are considering landing that experimentally in the compiler.

More ideas

• Improving interaction between return and closures
• Internals thread with more ideas
• Annoyances when using Rust

Ideas that didn't make it

• Add else match

[aturon]

Update: added the trait aliases RFC.

[aturon]

Update: added Extending ? to work with more types.

[aturon]

Update: added Delegation of impls

[aturon]

Update: added Add else match

[Ixrec]

@RUSshy Could you be more specific about what "adding class" means to you? Most languages with "classes" have dozens of distinguishable features associated with their classes, and Rust already has analogues for many of them.

[bestouff]

@RUSshy why wouldn't this work:

pub struct Entity : Drawable, Updatable
{
...
}

?

(Otherwise to me, the two most useful items are the ones in "Early stage thoughts", i.e. non-lexical lifetimes and module system improvements)

[Nemikolh]

@RUSshy It would give wrong impression to beginners in my opinion. One could believe that all the trait being implemented by a type would appear next to the class definition itself. But this is obviously not true (see Sync, Send or Into for instance).

Besides how would you deal with where clauses? What about bounds on type that apply to only specific trait impl but not others?

Would the code really be more readable at this point?

It seems, that you would definitely end up splitting your class into multiple impls as your code evolves.
Anyway, you can actually play with this class idea by writing a macro today. It would not look exactly as you have written it but would still save you a few braces. :)

[Ixrec]

i think having class to merge struct and impl can help something with readability, because i find myself repeating and write duplicate code

I don't see any duplicate/repeated code in your example, just three impl blocks merged into the struct definition. I do see the appeal of that sugar unifying "obviously related" blocks of code, but it is just sugar, and it doesn't appear to save very much typing or confusion compared to some of the other proposed sugars such as delegation, and with that particular keyword there's definitely a risk of misleading novices. I agree with Nemikolh that experimenting with a "class macro" would make more sense for now.

Though we should probably move this discussion to https://users.rust-lang.org/ or https://internals.rust-lang.org/ since it's at most a very tiny piece of the puzzle this issue is about.

[withoutboats]

My impression is that thread is for a high-level coordination of the work toward this roadmap goal. Brainstorming specific language feature ideas should be at either https://internals.rust-lang.org or an issue on the RFC repo https://github.com/rust-lang/rfcs/issues