DST custom coercions.

[nrc]

Custom coercions allow smart pointers to fully participate in the DST system.
In particular, they allow practical use of Rc<T> and Arc<T> where T is unsized.

This RFC subsumes part of RFC 401 coercions.

Rendered

[edited to add rendered link]

[nikomatsakis]

I don't quite know what "simple substitution of type parameters" means... but I think we want to check that both of them are applications of the same base type constructor. e.g. Foo<X> and Foo<Y> are ok, but not Foo<X> and Bar<Y>.

[nrc]

I meant that there exists some Ts (where Ts = a sequence of T) and some Xs such that Target = [Ts/Xs]Self and Self is not in Xs. Which I think subsumes your requirement, but also precludes some pathalogical cases such as Target = Foo<T1, T2>, Self = Foo<X, X>.

[nikomatsakis]

How does this include builtin coercions? There are some coercions, at least, that are not represented by the CoerceUnsized trait, right? I guess that's primarily the coercions around fn pointers and in particular unsafe fn items.

[nikomatsakis]

Sorry, in particular the safe to unsafe coercion, as well as the coercion from fn item to fn pointer. The latter doesn't matter too much in this context right now, but it might if we ever get a syntax for naming the type of a fn item (typeof foo, perhaps).

[nikomatsakis]

That said we could probably rewrite this rule as "if the type of the source is coercible to the type of the target", which encompasses a CoerceUnsized search.

[nrc]

I had assumed we wouldn't coerce other than using the one nested coercion since that might add complications to the compiler's representation. Also the motivation here is to support strictly DST coercions, not all coercions. I guess if we want to coerce Rc<Fn> to Rc<unsafe Fn> we need this. I'd be happier to add it later though and only if needed.

[nikomatsakis]

I believe it can handle Option<Box<T>> in the new design.

[eddyb]

I agree, but the rest of the RFC assumes only struct types.

[nikomatsakis]

I read over the revised version -- it seems pretty good to me, I left a few comments.

[eddyb]

Is this supposed to be implementing CoerceUnsized<NonZero<U>>?

[nrc]

yes

[eddyb]

Isn't this supposed to be a valid identifier, i.e. s/-/_/?

[eddyb]

I don't think this design can prevent writing functions generic over unsizing coercions - is that even desired?

[nrc]

You should use T: CoerceUnsized<U> for a bound and then I think it is possible. Using Unsize as a bound only really makes sense in the CoerceUnsized impls.

[eddyb]

An Unsize bound makes the CoerceUnsized impls applicable, which enables the coercions.

[eddyb]

Yes! I've done this in a local branch and now there's only unsizing coercion creation (typeck) and unsizing information generation (trans) that cares about the specific kind of unsizing being performed.
The later is even O(1), it ignores structure nesting completely.
This is how it looks like (I hope to replace root_target by the resulting pointer type):

// In the case of `&Struct<[T; N]>` -> `&Struct<[T]>`, the types are:
// * leaf_source: `[T; N]`
// * leaf_target: `[T]`
// * root_target: `Struct<[T]>`
pub struct AutoUnsize<'tcx> {
    leaf_source: Ty<'tcx>,
    leaf_target: Ty<'tcx>,
    root_target: Ty<'tcx>
}

[eddyb]

I forgot to mention, all of these (but the first one) are unsafe as they convert a Box<T> value into a reference/pointer that doesn't own the value, making it trivial to implement mem::forget.
None of the Box<T> -> ref/ptr to T coercions are currently implemented so not having them isn't a breaking change.

[eddyb]

&'a mut T not &mut 'a T. Also, why is this one so strict, surely shorte- oh, I see!
This is supposed to be used inside a structure, where &'a mut T is invariant.

Which makes me wonder, how can I enforce that?
Does subtyping handle &'a mut T being invariant and &'a T contravariant wrt 'a?

[eddyb]

Actually, come to think of it, this is by-value so it should be fine to have both &mut T -> &U and &mut T -> &mut U capable of shortening the lifetime.

[nrc]

I think this is true. I'll probably leave the RFC as is, since that reflects the implementation. But it does feel we could make this more flexible.

cc @nikomatsakis

[eddyb]

Missing 'b: 'a here. Also, all the Self types should contain T not U.

[eddyb]

And lifetime params come before type params. I had to try to compile it to actually find that out...

[eddyb]

This shouldn't make T and U unsized, NonZero wraps scalars (they also both need a Zeroable bound).

[nikomatsakis]

@nrc did you plan to incorporate @eddyb's feedback here?

[nrc]

I do, I had forgotten this was not merged yet.

[nikomatsakis]

Hear ye, hear ye. This RFC is now in final comment period until June 2nd.

[nikomatsakis]

This RFC has been accepted. It is not yet merged to allow @nrc to incorporate final comments reflecting the current design. (It has been partially implemented in the meantime.)

-- Language design subteam

[nrc]

@nikomatsakis updated

[nikomatsakis]

Merged. Tracking issue is rust-lang/rust#18598