👍

Related bug: rust-lang/rust#13703. I hit that one all the freaking time. I'm ecstatic to see people are thinking about solutions to this issue.

Discussed at https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-08-12.md.

Accepted as RFC 49.

Man, this was fast. I hadn't even read it yet. But now that I have I don't have anything to add, other than +1. (I haven't fully understood the tension between the various forms of inference the RFC doesn't propose doing, but not inferring is safely forwards-compatible and can be liberalized later, so I agree with this as well, even without understanding it yet.)

There's one thing I've been thinking about however, and this seems like an appropriate place to ask about it:

Is there ever a use case for lifetime parameters on types to be anything other than contravariant? As a subcase: is it ever preferable to have the lifetimes on (higher-order) function parameters be fixed from outside, instead of higher-rank?

E.g., do you ever want something like:

struct Foo<'a> {
    f: fn(&'a Bar) -> ...;
}

instead of

struct Foo {
    f: <'a> fn(&'a Bar) -> ...;
}

?

The reason I'm wondering is that if we can declare that lifetime parameters on types are always contravariant, then we can avoid the need for any kind of variance inference or annotations, which would be very nice. (This would also nicely plug the hole in lifetime elision w.r.t. covariant lifetimes: if covariant lifetimes on types are impossible, then avoiding their elision is trivial.)

My "grand plan" would also involve making type parameters be always invariant , and using Transmute/Coercible any time you want to safely change the types or lifetimes of inner types (type arguments). With the new 'a: 'b bounds the relevant impls could even be written in the language itself, instead of being magically wired-in: impl<'a, 'b: 'a, T> Transmute<&'a T> for &'b T { } (and likewise for &mut).

On Wed, Aug 13, 2014 at 09:11:05AM -0700, Gábor Lehel wrote:

E.g., do you ever want something like:

struct Foo<'a> {
    f: fn(&'a Bar) -> ...;
}

instead of

struct Foo {
    f: <'a> fn(&'a Bar) -> ...;
}

This is supported and will be inferred to be covariant. However, this has seen very little use.

The reason I'm wondering is that if we can declare that lifetime parameters on types are always contravariant, then we can avoid the need for any kind of variance inference or annotations, which would be very nice. (This would also nicely plug the hole in lifetime elision w.r.t. covariant lifetimes: if covariant lifetimes on types are impossible then avoiding their elision is trivial.)

No, we cannot do this, there are definitely times when lifetime
parameters must be invariant. For example, 'b in a struct definition
like:

struct Foo<'a,'b:'a> {
    foo: &'a mut Foo<'b>
}

However, I have been contemplating a plan to make:

• lifetime parameters contravariant by default
• type parameters covariant by default in types
• a mut prefix to declare invariance

I wanted to gather some data and was hoping to do it in the next few days.

Obviously this plan loses some expressiveness, though nothing that
couldn't be regained with some more potential annotations. One problem
with this plan is what to do about associated types (today: trait type
parameters -- which reminds me, I need to make a note on the RFC).
With the move to unboxed closures, fn types generally become object
types, and hence we may be unsatisfied without contravariance and
covariance. And it's not clear to me that the transmute plan below can
address this.

My "grand plan" would also involve making type parameters be always invariant , and using Transmute/Coercible any time you want to safely change the types or lifetimes of inner types (type arguments). With the new 'a: 'b bounds the relevant impls could even be written in the language itself, instead of being magically wired-in: impl<'a, 'b: 'a, T> Transmute<&'a T> for &'b T { } (and likewise for &mut).

I guess it'd be worth experimenting a bit. The last few times I
investigated "removing subtyping" it wound up either breaking a lot of
code or essentially being reintroduced through increasingly elaborate
coercion rules. I will note that I frequently encounter problems
because Option<&'a T> is (currently) invariant with respect to &'a T. Aggressive use of the Transmute relation would likely help here
in many cases, though it adds its own complications around inference.