More implicit bounds (?Sized, ?DynSized, ?Move)

[kennytm]

The concept of implicit bound was introduced together with dynamic sized type. While having a : Sized bound is more specialized than no bound at all, we expect that : Sized is much more common, and thus should be present by default. We introduced the : ?Sized syntax in #490 to opt-out of this default bound. The syntax : ?Sized is called "relaxed bound".

Later, new RFCs and PRs tried to introduce more traits like Sized which the common case is "this should be implemented", e.g.

• Immovable types  #1858 and Immovable types prototype where the Move trait is builtin rust#44917 introduced the ?Move bound, since most types do not contain internal references and thus can be freely moved around.
• Opaque Data structs for FFI #1993 and Add DynSized trait (rebase of #44469) rust#46108 introduced the ?DynSized bound, since most types have known size and alignment at runtime.
• https://gankro.github.io/blah/linear-rust (semiseriously) introduced the ?Leave bound, since most types can be drop'ed.

These traits themselves are often necessary at language level beyond trait bounds, e.g. Move is needed for immovable generators (for lack of a better solution), DynSized is needed to reject struct tails without known alignment, and Leave is needed to support linear type.

However, the expansion of implicit bounds experienced push back from lang team due to ergonomic cost, that

• ?Sized itself being a "negative feature" confuses users, adding ?Move and ?DynSized will only make the situation worse,

• introducing new relaxed bound means downstream packages will need to reevaluate every API to see if adding : ?Trait makes sense, and this needs to be done for every new relaxed bound.

• the necessity of Move and DynSized is orthogonal to whether they need to be default.

• the backward-compatibility may be a lie 🍰 — Relaxing the bounds in associated type, in particular FnOnce::Output, means the user of the trait will get less promises, which is a breaking change:

  let should_be_movable: Closure::Output = closure();
  let but_it_errored = should_be_movable;

  Essentially, the bounds on an associated type cannot be added (which breaks implementers) or removed (which breaks users).

So the questions are,

• Should we embrace ?Trait and allow language to grow more similar traits, despite the stated problems above?
• If we decide to stop at ?Sized, what else should we do regarding Move and DynSized?
• Would there be a balanced solution in the middle of the two extremes?

---

I am filing this issue here to Move the discussion from those two different PRs to a potentially more proper place, as it seems having a non-Sized relaxed bound itself should require more discussion around the language design.

[est31]

?Sized itself being a "negative feature" confuses users, adding ?Move and ?DynSized will only make the situation worse,

I think it will make it better, because sized is right now one single exception. If there are more of it, it becomes more of a rule.

[mikeyhew]

@kennytm I think some of your links go to the wrong comment... the last three all go to the same comment by @arielb1

[Manishearth]

Relevant: https://gankro.github.io/blah/linear-rust/

(I really would like more implicit bounds, however I am concerned about making things too complicated)

[Manishearth]

Worth noting that while Sized currently is not implied in many cases (e.g. on a trait) we probanly should make things like Move get implied everywhere, and require explicit where Self: ?Move to opt out.

[eddyb]

@Manishearth I'd expect it to be written more often as trait Foo: ?Move.

[kennytm]

@mikeyhew thanks, I’ll update it after the holiday.

Edit: Fixed links.

[crlf0710]

Is there a "induction based" solution? I mean, what if

trait Foo {
    fn foo1(&self);
    fn foo(self);
}

automatically implies

trait Foo : ?Sized + ?DynSized + ?Move + ... {
    fn foo1(&self);
    fn foo(self) where Self: Move;
}

The (naive) idea is that wherever 'move operation' is implied in the method signature, an implicit 'where clause' requiring the type is Move is automatically added on a method basis. The existence of Move bound should automatically assume Sized and DynSized, i think...

On the concrete type side, make these auto trait. So they're automatically inferred just like Send and Sync...

I wonder if this can work?

[withoutboats]

In addition to the concerns @kennytm identified in the original post, it appears that adding additional ?Traits is not backwards compatible - in the case of ?Move this is a very serious problem for the proposal because of how it interacts with the return values of closures.

In terms of usability, the deep problem with these traits is not that they're weird or confusing, but that by their nature they make some question into everyone's problem. Making more of them does not reduce the problem, it multiplies it.

Today, it is everyone's problem to know if they really need to know the size of this type at compile time. Tomorrow, we would have everyone also worry about whether they need to know the size at runtime, whether they need to be able to move it after they reference it, and whatever else anyone might propose to use these kinds of traits for.

I'm pretty certain we can't add any additional traits like this, and both DynSized and Move need to discover an alternative solution.

Fortunately, I think this has been a situation where we have a sledge hammer, and people have picked it up and swung it. That is, both DynSized and Move feel like very brute force attempts to solve the problem they are aiming at, and with more finesse we could develop more balanced and targeted solutions to these problems.

[arielb1]

Not all traits are born equal

DynSized feels less terrible than Move, because of trait Sized: DynSized - that's it, it only makes sense to consider Sized vs. DynSized when you're adding a ?Sized bound anyway.

You need a T: ?Sized + DynSized type exactly when you are handling T behind a safe smart pointer. Code that doesn't handle safe smart pointers generically doesn't need to know about the distinction, which is a small amount of library code.

In fact, the main place that non-data-structure code cares about DynSized vs. Sized is in impls - e.g. impl<T: ?Sized + Foo> Foo for Box<T>. In that case, the impl itself doesn't require anything but ?DynSized, and with implied bounds, the user could always type T: ?DynSized and add other bounds when the compiler prompts them (or, with implied bounds, never).

Move is basically the opposite - as the C++ STL shows, many data structures and algorithms can be made uglier while working with !Move types, which means that !Move might cause a split of the data-structure ecosystem.

On the other hand, the payoff of non-movable types is fairly large - easy safe self-borrowing generators! Because generators sit at the corner of complicated, high-performance, hostile-data-handling code, making them usable safely is a big safety and quality-of-life improvement, possibly even worth an ugly "data structure ecosystem split".

NEEDSRESEARCH

BTW, I didn't research this, but how bad is the issue with Move closure return types? Today stable code has to use them like T, F: FnOnce() -> T, where T has an implicit Move bound.

[arielb1]

Moving is a big decision

Actually, taking a second look, it might seem that we make trait Move: DynSized, then DynSized might "cancel out" the collateral badness of Move.

That's it, you might think you could have the following mental model:

1. If you are working with an "ordinary" T, then you probably want T to be both Move and Sized, so you can have an unannotated type parameter - in the worst case, the user can always get that by sacrificing some performance and adding a Box.
2. If you are "delegating" and don't care what T is, you can require T: ?DynSized and let implied bounds (or bound copy-pasting) do the rest.
3. If you are writing a generic container, then you should know what you are doing and put the right bounds.

The reason this is not as perfect as it looks like is that there are actually not that much non-delegating uses of Sized types: if you pass a type by-value to a function, or put in an enum or a middle field of a struct, then that type must always be Sized! Because most uses of generic types end up doing that, almost all non-"relay" type parameters are required to be Sized.

On the other hand, exposing a reference to a type and then moving it is a much rarer thing - there are many places where T: ?Move makes sense, or where T: Move makes sense, or where both make some amount of sense and the programmer has to choose what they want to implement and/or guarantee.

The "moving is a big decision" problem is a far bigger thing than worries about backwards-compatibility. It makes the mental model for anyone who is writing generic code more complex - do I want to commit to allowing T to be movable? Might I ever want to move it around? These are not obvious questions, and their implications might be even less obvious.

On the other hand, that makes !Move again far more strategic than closing a corner case where size_of_val panics/return None/whatever does. Being able to work with immovable data is a very powerful and often requested feature for high-performance code. However, if we can find some other 95% solution to that that does not force every programmer to make a decision, that would be much better.

[mikeyhew]

So, I just posted something over in internals https://internals.rust-lang.org/t/pre-erfc-lets-fix-dsts/6663. There's a lot of stuff in that post, but I had an idea as I was writing that that could help with the issue of ? traits. I'll try to distill it down to the relevant bits.

Part of that proposal involves adding a Referent trait, which every type implements. For reference, here is a list of traits and their supertraits:

Referent
DynAligned: Referent
DynSized: DynAligned
Aligned: DynAligned
Sized: Aligned + DynSized

I've taken out SizeFromMeta and AlignFromMeta to make things a bit simpler.

So the idea is, Sized is still a default trait bound, but as soon as one of the above traits is listed as a trait bound, the default bound is removed. So instead of T: ?Sized, you write T: DynSized, and instead of T: ?DynSized you write T: Referent.

Here is an example from the post I linked above:

// `T: Referent` makes it clear that `T` is any type that can be pointed to
fn assemble<T: Referent>(data: *const (), meta: T::Meta) -> *const T;

I think this makes things easier to reason about. I know @withoutboats was saying that that's not the issue here, but I have a hunch that the ?Trait syntax really does make things confusing, and life would be a lot better without them. When you write ?DynSized, it means "we won't necessarily be able to get the size or alignment of a value at runtime", whereas if you write Referent it means "something that can be pointed to, and nothing more". The argument for DynSized in favour of ?Sized is even stronger, I think. When you see T: DynSized, you think, "Oh, it can be dynamically-sized".

It's altogether a reduction in cognitive load, because you stop having to worry about which trait bounds are there that you can't see. (And then if you didn't write any of those traits, Sized is still there by default, so you don't have to think about it unless you're doing something fancy where it's not Sized)

I'm not quite sure how this works with Move. I guess it could be included in the list of traits that removes the default bound... that way if you write T: Move, it implies T: DynSized and removes the T: Sized bound.