Ergonomics initiative discussion: Allowing owned values where references are expected

[withoutboats]

@rkruppe is right about this being a separate feature. These ref/deref coercions all happen at the method call site, you can think of them transformations of self.method(arg) into the ‘canonical’ <T as Trait>::method(self, arg). We don’t ever actually coerce between the types that those methods have right now.

I think I’d be more eager to see Scala style ‘lambda shorthand’ than these type level coercions, like a.map(self.foo($)) as a shorthand for a.map(|x| self.foo(x)) or something along those lines.

[shepmaster]

I don’t think this proposal would allow that

this being a separate feature

It seems like both of you are operating with the knowledge that there’s already a planned implementation for how to address this ergonomic initiative, we plan on no further improvements, and my example will not be solved by that implementation. If this has already been formulated and decided upon, I apologize for wasting time. I’d appreciate being pointed to the appropriate RFC / issue / internals thread so I can read up.

Otherwise, I still feel like this fits squarely under the “use owned values where references are expected” banner. I have a closure where both an owned value and a reference already work using the longer syntax. When I change to shorter syntax, it no longer works. If there’s a proposed implementation that doesn’t “fix” this case, perhaps that implementation also doesn’t “fix” the ergonomics goal (or to the extent we want).

As a familiar user of the language, I get caught on this more than I care to admit. I’d expect (but have no proof) that people newer would hit it more frequently.

[withoutboats]

The feature that we had in mind is only vaguely sketched, but its about applying coercions to non-receiver arguments along the same lines as the deref coercions that method receivers get. As @rkruppe pointed out, the feature you’re talking about applies equally well to the existing coercions the receiver gets (coering an &self method to an Fn(Self)), and so even if we didn’t do that this feature request would still be relevant.

Its not a bad request and I agree that the current behavior is a bit of a wart (and probably why the ‘point free style’ is not more popular). I am a bit skeptical it will work well with type inference and existing coercions though - if I’m wrong I’d be happy to find out.

[withoutboats]

The original proposal was essentially just that if you have an argument &T, and pass a type U where U: AsRef<T>, the compiler will accept it and insert an as_ref coercion. The justification was that:

• It would let you pass a T to an &T argument, but you would lose ownership, in other words ‘both sides get what they want.’
• The APIs that take e.g. P: AsRef<Path> become cluttered and difficult to understand, but are very popular. Let’s just build that into the language so its not distracting in the API surface.
• AsRef coercions are necessarily cheap (unless doing some pathological side effect) because they have to return a reference (this is unlke Into).

We could also consider the same thing with AsMut and &mut T but I’m concerned with how that would essentially create a C++ call-by-reference situation for Copy types:

let mut x = 0;
let mut y = 1;
mem::swap(x, y);
//x is now 1 and y is now 0, because swap takes &mut T, &mut T

@shepmaster’s idea actually fits into this in a sort of interesting way: we could define some analog to AsRef for function types so that essentially fn(&T): AsRef<fn(T)>. In other words, its not that the coercion happens at the level of the type but still just when passing the argument (so an fn(&T) is not coercible to fn(T) in general).

(Its also interesting that this ownership coercion is essentially contravariant for higher order functions, just like subtyping.)

EDIT: I also remember that we probably want to apply any AsRef coercions to binary operators as well, isislovecruft posted an RFC issue which this would be a solution for: https://github.com/rust-lang/rfcs/issues/1936

[Nemo157]

We could also consider the same thing with AsMut and &mut T but I’m concerned with how that would essentially create a C++ call-by-reference situation for Copy types:

let mut x = 0;
let mut y = 1;
mem::swap(x, y);
//x is now 1 and y is now 0, because swap takes &mut T, &mut T

It doesn’t seem like it should be possible to see the effects of the swap in this case. I would expect the expansion to be equivalent to something like

let mut x = 0;
let mut y = 1;
{
    let mut x = AsMut::as_mut(_copy(x));
    let mut y = AsMut::as_mut(_copy(y));
    mem::swap(x, y);
}
println!("{}, {}", x, y); // => "0, 1"

Basically the Copy expansion would happen inside the AsMut expansion, so you would be passing in mutable references to temporaries, not the original values. It could be annoying that the code compiles at all since it’s a no-op, but maybe there could be a lint for some functions that don’t make sense to be called via AsMut.

Random thought, this would make the following two statements equivalent:

mem::swap(&mut x, y);
mem::replace(&mut x, y);

[bluss]

AsRef is not complete as it is: T does not implement AsRef<T>, except in a few special cases. This seems to me a major missing thing before any kind of automatic coercion goes through AsRef.

The discussion here seems to presume a different state of the AsRef trait than the present.

[JeffBurdges]

Aren’t Borrow and BorrowMut the right traits for this?

In any case, there are big foot guns here so actually doing this stuff should wait until the current effort to unify the handling of ref in pattern matching in for and match reaches some conclusion and even approaches stabilization. Of course, this discussion is helpful in clarifying what should happen with match patterns.

[withoutboats]

This is true but it will be rectified as soon as we have intersection specialization. If this feature were to be implemented earlier we could have the rule by T | U: AsRef<T>.

[withoutboats]

It doesn’t seem like it should be possible to see the effects of the swap in this case. I would expect the expansion to be equivalent to something like

This is interesting; there are essentially two desugars we could use here:

// Given:
foo: fn(&T)
x: U where U: AsRef<T>

// Surface code:
foo(x)

// Desugaring A:
foo(AsRef::as_ref( { x } )) // note the braces forcing a move (therefore a new copy)

// Desugaring B:
foo(AsRef::as_ref(x))
drop(x) // drop after asref

Your interpretation is the “braces” version, whereas mine was the “drop” version. I think the braces version is more elegant. I worry it will still surprise people though, just in that they expected call-by-ref behavior.

Aren’t Borrow and BorrowMut the right traits for this?

The choice of AsRef was to support more flexible conversions like String -> Path but this is definitely an open question.

[djc]

For what it’s worth, having to use foo(&bar) where bar is an owned type and foo() takes a reference was one of the reasons that caused me to cast aside Rust on one of my first attempts to write it. To me, since non-mutable references are cheap and harmless to create, there’s not a lot of value in making it explicit at the call sites.

I do feel that the trade-off is quite different for &mut, though. Making mutability explicit in argument passing feels very useful even independent of the borrow checker, and it protects users from a different class of errors.

[shepmaster]

To me, since non-mutable references are cheap and harmless to create, there’s not a lot of value in making it explicit at the call sites.

My understanding of the proposed feature is that you’d still have to take an explicit reference if you don’t want to transfer ownership. In code:

struct Thing;

fn foo(_: &Thing) {}

fn currently_does_not_work_but_would_with_the_proposal(thing: Thing) {
    foo(thing);
}

fn would_not_work_even_with_the_proposal(thing: Thing) {
    foo(thing);
    foo(thing); // Probably "Error: use of moved value"
}

Are you proposing that the second example should work? That feels similar to C++'s pass-by-reference.

[djc]

Yeah, I was expecting that your second example would work. It seems like it’d be pretty surprising if you pass an owner binding to a function that takes a reference, and suddenly it ends up being moved. I guess it might be okay if you have a good error message about it, but to me the Do What I Mean behavior is more like just adding the & where needed.

[oli-obk]

I guess it might be okay if you have a good error message about it

We already have an error message for this:

struct Bar;

fn foo(_: Bar) {}

pub fn main() {
    let bar = Bar;
    foo(bar);
    let baa = bar;
}

error[E0382]: use of moved value: `bar`
 --> <anon>:9:9
  |
8 |     foo(bar);
  |         --- value moved here
9 |     let baa = bar;
  |         ^^^ value used here after move
  |
  = note: move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait

The only difference we’d now have, is that foo would be fn foo(_: &Bar) {}, so the error message could include

help: did you mean to pass by reference: foo(&bar)

in case of implicit owned->ref conversion

[nikomatsakis]

Yeah, I was expecting that your second example would work. It seems like it’d be pretty surprising if you pass an owner binding to a function that takes a reference, and suddenly it ends up being moved. I guess it might be okay if you have a good error message about it, but to me the Do What I Mean behavior is more like just adding the & where needed.

I can understand why this is surprising. OTOH, I’ve definitely found the opposite in the past as well (when Rust used to do more coercions by default, such as when we used to do Box<T> -> &T by default) – that I found it confusing to see foo(x) not as a move of x but rather a borrow. It’s nice to able to reason relatively locally about where things get moved or borrowed, particularly given how important borrows are for the borrow checker’s rules.

[aturon]

AsRef is not complete as it is: T does not implement AsRef<T>, except in a few special cases. This seems to me a major missing thing before any kind of automatic coercion goes through AsRef.

We don’t need (or really want) this reflexive impl for the coercion. Coercions generally apply when the type wouldn’t otherwise match. If you’re in a context where you have &T and &T is expected, coercions won’t even be used.

[aturon]

Aren’t Borrow and BorrowMut the right traits for this?

I don’t think so; those traits are more restrictive, and generally apply only to slice/owned views of types, where you expect equality, hashing, etc to be the same. AsRef, by contrast, just says that you can view one reference type as another.

What led you to think that Borrow would be better?

there are big foot guns here so actually doing this stuff should wait until the current effort to unify the handling of ref in pattern matching in for and match reaches some conclusion and even approaches stabilization

Can you elaborate? What footguns do you see? And what’s the relation to the match proposal?

[aturon]

It seems like both of you are operating with the knowledge that there’s already a planned implementation for how to address this ergonomic initiative, we plan on no further improvements, and my example will not be solved by that implementation.

A bit of background: Rust makes a distinction between coercion and subtyping. Coercions only apply at the “top level” of a type – so you can go from &&T to &T, but not Vec<&&T> to Vec<&T>. Subtyping comes in with lifetimes, and triggers at all levels: you can go from &[&'static T] to &[&'a T].

Now, consider what it would take to allow coercions to apply deeply; in a case like Vec<&&T> above, you would actually have to create a new vector, because you’re changing the elements in a significant way. Even if we could give you the tools to tell Rust how to do this, it’s not the kind of thing we would generally want to happen as part of an implicit coercion, I think.

However, there might be potential to apply coercions in more places than today, without applying them arbitrarily deeply. Here’s how I would think of it:

• The AsRef proposal is about adding a new coercion based on AsRef, which fits into our existing coercion story.
• Separately, as a distinct ergonomics improvement, we should ask whether there are situations where we can apply coercions at the function level in general. It seems quite plausible – it would effectively be sugar for writing a closure that simply calls the function (i.e., |x| f(x)), which would apply coercions.

I’d suggest starting a separate thread on that extension, and linking to it from the Ergonomics Roadmap tracker.

[JeffBurdges]

What led you to think that Borrow would be better?

Just my own poor understanding probably.

Can you elaborate? What footguns do you see? And what’s the relation to the match proposal?

I’d miss-understood proposal. It’d be dangerous to treat a mut X as a &mut X and continue using it after the call mutates it, but consuming an X by value so that you cannot use it later, while passing the &mut X sounds completely fine.

If anything, consuming by value to pass an &mut focuses the &mut noise onto the real mutable borrows and makes the code easier to read.

[withoutboats]

We don’t need (or really want) this reflexive impl for the coercion. Coercions generally apply when the type wouldn’t otherwise match. If you’re in a context where you have &T and &T is expected, coercions won’t even be used.

But if we’re talking about passing owned values we pass a T to a function that takes an &T; without the reflexive impl we need a special case for that.

What led you to think that Borrow would be better?

I can see the argument: because of the restrictiveness on borrow, its more conservative than using AsRef - you can pass strings as string slices, but not as paths. However I don’t think this is an upside - because Borrow’s restrictions are entirely unenforced, if we do this we encourage violating those restrictions & potentially lead to people with broken hashmaps.

[shepmaster]

I’d suggest starting a separate thread on that extension, and linking to it from the Ergonomics Roadmap tracker.

I’m still really confused; but I think most of all I’m looking for an explanation about why my request is not part of completing the the initiative Allowing owned values where references are expected, which is the feeling that I get from phrases like “starting a separate thread”, “it’s a separate thing”, “a separate feature”. My guess is that I do not understand the true scope of the initiative.

• If my request falls under the initiative, but is impossible to fix, I’d like to know that.
• If my request falls under the initiative, but we don’t care to address it (at least this year), I’d like to know that.
• If my request has nothing to do with the initiative as worded, I’d like to understand why not. I’d then like to help rephrase the initiative to help avoid anyone else from being confused in the same way, and to help set expectations for the eventual feature.

---

With that request made, I’ll attempt to restate my position to reduce any confusion I might have introduced. Using the previous code, this is my understanding of the state of the world with the initial proposal.

free function

struct Thing;

fn foo(_: &Thing) {}

fn currently_does_not_work_but_would_with_the_proposal(thing: Thing) {
    foo(thing);
}

fn currently_does_not_work_but_would_with_the_proposal_also(thing: Thing) {
    Some(thing).map(|t| foo(t));
}

fn would_not_work_even_with_the_proposal(thing: Thing) {
    Some(thing).map(foo);
}

We will be able to transfer ownership of objects to methods expecting references.

method

struct Thing;

impl Thing {
    fn foo(&self) {}
}

fn currently_works(thing: Thing) {
    thing.foo();
}

fn currently_works_also(thing: Thing) {
    Some(thing).map(|t| t.foo());
}

fn currently_does_not_work_but_would_with_the_proposal(thing: Thing) {
    Some(thing).map(|t| Thing::foo(t));
}

fn would_not_work_even_with_the_proposal(thing: Thing) {
    Some(thing).map(Thing::foo);
}

This is a place where an owned value is already allowed to act as if it is a reference (map(|t| t.foo()), but not when using a different syntax that appears equivalent (map(Thing::foo)). The proposal will make it even closer (map(|t| Thing::foo(t))) which means the fact that the non-functional syntax is even harder to explain.