Language ergonomic/learnability improvements

@nikomatsakis

Point of contact

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

Ideas that didn't make it

Add else match

Update: added the trait aliases RFC.

Update: added Extending ? to work with more types.

Update: added Delegation of impls

Update: added Add else match

@RUSshy

@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.

@RUSshy

@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)

@RUSshy

@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. :)

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.

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

Update: adding reference to this thread on internals which discusses some additional ideas.

Update: added match ownership ergonomics.

One idea that would make working with capn proto and similar systems so so much nicer would be something like attributes as exist in C# or Python, where one can use field access syntax but underneath call functions to get/set the field. The current state of the art in Rust is explicit getters and setters, which leads to terrible ergonomics for code interacting with data at the edges of the process boundary, to the point of Java-level verbosity. In the past (pre-1.0) I know there was some discussion and rejection of this, but I'd like to bring it up again.

@nikomatsakis

Added:

Coercions into Result when leaving a block (@nikomatsakis)
- Good mentored RFC!

@aturon

you're welcome to make an internals thread on the topic

@aturon I've created a thread as requested. We'll see where it goes ;-)

Updated to add some ideas around coercions, e.g. https://internals.rust-lang.org/t/ergonomics-initiative-discussion-allowing-owned-values-where-references-are-expected/5161/22?u=aturon

Updated with the latest status info.

@burdges

Any news regarding PartialEq/PartialOrd? I find @burdges's solution elegant and nobody suggested any problems.

It would also solve the weirdness where current bound Ord: PartialOrd<Self> means "for a type to be Ord, it must be PartialOrd first", whereas the true mathematical relation is that Ord is automatically PartialOrd<Self>, Eq and PartialEq<Self> as well, by virtue of Ord subsuming all those properties, so encoding the relationship in a trait bound actually makes no sense.

@le-jzr

@le-jzr I'd love to have automatic implementations like that - it'd also be possible to implement Read automatically for BufRead types. We may need to wait until after specialization stabilizes to be able to add them, though, since I believe you need to enable the feature to specialize an implementation.

I think this RFC ("Allow comparisons between integers of different types") is also relevant here. Much like default binding modes for match, it takes a case where the compiler today issues errors and forces people to manually write boilerplate and makes it just do the obviously right thing instead. (Except in this case, the manual boilerplate is also highly error-prone.)

use inside trait definitions.

Local use statements are an extremely cool rust feature. But unfortunately, there're some places where you can't use them. One of such places are trait definitions.

Long story short, I want to be able to write something like this:

trait Foo {
    use std::iter::IntoIterator;
    // ...
}

@suhr

@suhr: That's rust-lang/rfcs#1976, and it's about to get postponed.

It turned out trickier than folks thought. I think you can mostly work around it using submodules judiciously.

mod UseNo1 {
use std::iter::IntoIterator;
pub(super) trait Foo { ... }
} // UseNo1
pub use UseNo1::*;

it's about to get postponed

Well, that's unfortunate.

I think you can mostly work around it using submodules judiciously.

It's an ugly and awkward kludge that is not worth it.

I wonder if this would get a different reaction in the context of this thread.
RFC: rust-lang/rfcs#2063
link to text:
https://github.com/dobkeratops/rfcs/blob/infer-function-signatures-from-trait-declaration-into-'impl's/text/infer%20function%20signatures%20from%20trait%20declaration%20into%20impls.md

alternating between languages, I continue to find the need to micromanage traits to be irritating (i.e. the single function trait case), but strangely in haskell the typeclasses don't feel as bad. It's because the there, defining and referring to the 'type class' saves you writing details out again. Initially I found it odd, but their function signatures being split are actually clearer.

Hence this PR.

People are complaining 'you read it more than you write it' but it's the repetition that is annoying: if I'm specifying the types , I would rather it figures out the trait from them. If I've specified the trait, it makes sense to use that to infer the types. Users are going to read the trait declaration itself more surely, which has all the types, and you need to refer back to that to implement anyway, surely. Aren't you just taking up more screenspace in a useless way displaying it again. The trait defs are very easy to grep for ( i have that all working nicely in emacs), and there's rustdoc too.

Something else to mention is this mental flip of arguments in the single-function-trait case (e.g. used for overloading)..

I wish you could write the impl the other way round so that it's impl Type:Trait<..> , so the types appear in the same order as the function definition
e.g.

    // "I want to implement LHS.add(RHS)->Output"
    impl LHS:Add<RHS> { type Output=..;    // trait: "LHS,add, RHS, Output.."
     //  |          |           |
        fn add(&self,rhs){... }       //function: "add LHS,RHS,Output"
    }

wouldn't that be so much bettter? the mental flip between the intent "LHS,add,RHS" and expressing the trait makes the trait so much more annoying.

Again the 'multi-parameter-typeclass' case in haskell is more pleasant, possibly because you get to choose the order, so in the case of 'a single function class' you can write the class-types in the same order as the function types. (there's extra symmetry from the fact they have no 'self', but with better ordering I don't think special-Self would be a pain)

Combined with eliding the signature types, that might be enough for me to achieve peace with this system.

I believe mutability, references, lifetimes, etc. change that calculation somewhat from Haskell, so maybe wait until folks become more comfortable with lifetime elision for impls rust-lang/rust#15872 ?

At least one can then deduce if type elision ever confuses the reader familiar with lifetime elision. If so, type elision could be restricted to cases where lifetime elision works. And maybe it should be restricted to not doing muts anyways.

most of the time operators are just reference inputs, and the lifetime elision kicks in;
Thinking in C++, I'm used to 2 main cases which are both quite simple:

'accessors' ('self assumption' which Rust successfully allows elision for - this is great) ,
and 'no returned references'/'independent result' (harder to give this a catchy name, but basically 'there are no returned references to worry about' - any pointers are fully owned and managed by the result; I appreciate the need to mark up the difference, however I still suspect there might be an easier way to do this: often there's still a gap between my intent ("no escaped references", and the nature of the markup'(ok, show it which references in the inputs correspond to each other, specifically')

So basically the times you actually need to write lifetimes, you're doing something rarer (IMO).

Eliding information in the obvious cases will give you more 'cognitive budget' to spend on the unusual.

Also the information is still there and will surface if you hit compile.

I argue people reading code are more likely to be reading the trait, which does have the full types.

also I argue haskell's split is actually helping readability, regardless of how much type information there is

Conversely if I must write out the types then I'd prefer it to do the opposite: figure out the trait from the types.

This reminds me of years of people in C++ claiming "writing out the iterator types is good for you..", delaying the deployment of 'range based for', 'auto' ..

Navigation Menu

Repository navigation

Language ergonomic/learnability improvements #17

Point of contact

Overview

Status

Ownership/borrowing

RFCs

Sketches

Traits

RFCs

Sketches

Module and privacy system

Landed

RFCs

Sketches

Error handling

RFCs

Primitive types/core traits

Sketches

Type annotations/verbosity

RFCs

Sketches

FFI

Landed

Other

RFCs

More ideas

Ideas that didn't make it

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Language ergonomic/learnability improvements #17

Description

Point of contact

Overview

Status

Ownership/borrowing

RFCs

Sketches

Traits

RFCs

Sketches

Module and privacy system

Landed

RFCs

Sketches

Error handling

RFCs

Primitive types/core traits

Sketches

Type annotations/verbosity

RFCs

Sketches

FFI

Landed

Other

RFCs

More ideas

Ideas that didn't make it

Activity

aturon commented on Feb 1, 2017

aturon commented on Feb 1, 2017

aturon commented on Feb 1, 2017

aturon commented on Feb 1, 2017

Ixrec commented on Feb 7, 2017

bestouff commented on Feb 7, 2017

Nemikolh commented on Feb 7, 2017

Ixrec commented on Feb 7, 2017

withoutboats commented on Feb 7, 2017

aturon commented on Feb 10, 2017

aturon commented on Feb 10, 2017

emberian commented on Mar 3, 2017

33 remaining items

aturon commented on Apr 29, 2017

shepmaster commented on Apr 29, 2017

aturon commented on May 4, 2017

aturon commented on Jun 7, 2017

le-jzr commented on Jun 9, 2017

sfackler commented on Jun 9, 2017

glaebhoerl commented on Jun 12, 2017

suhr commented on Jun 23, 2017

crumblingstatue commented on Jun 23, 2017

burdges commented on Jun 23, 2017

suhr commented on Jun 23, 2017

dobkeratops commented on Jul 25, 2017

burdges commented on Jul 25, 2017

dobkeratops commented on Jul 26, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions