Type conversions

[nrc]

Casting and coercions. Adds custom DST coercions for smart pointers. Otherwise, mostly descriptive, with a few bits of tidying up.

rfc text/

[Gankro]

rendered (draft)

[Gankro]

Finally! ❤️

[Gankro]

"is a new coercion"

[Gankro]

Does this need some kind of where clause for U: CoerceUnsized<T>?

[nrc]

No, I don't think so. U is just the pointed-to data, it does not need to be coercible. The RcBox is unsized using the fat_pointer_convert intrinsic and automatically has the required Unsize bound.

[comex]

How does that work? As written, it seems like you could [manually] call coerce() to convert any Rc<T> to any other.

[nrc]

Yeah, actually I guess you do need a where clause on the impl - where U: Unsize<T>. Given that where clause the compiler can derive that RcBox<U>: Unsize<RcBox<T>> an thus that we can call fat_pointer_convert.

[ben0x539]

I don't see it spelled out here (but I guess neither are numeric casts), *T -> *U is gonna remain a cast, right?

[Gankro]

No casting from u8 to u32 or u32 to u8?

[nrc]

Numeric casts are an omission, I'll add them in.

@ben0x539 what are T and U here? Do you mean an arbitrary cast from one raw pointer type to another?

[ben0x539]

Yeah, *T -> *U for any T and U with any combination of mutability seems to be accepted right now but I'm not seeing it listed here. Would be sad to see it go away!

[ben0x539]

typo, "recevier"/"receiver"

[ben0x539]

When is a second address-of operation necessary?

[nrc]

When the impl is for &T (for some T) and the method takes self by reference (&self). This was common pre-DST, but even with DST it still happens enough to be required.

[michaelsproul]

*tweaks

[Gankro]

*V?

[ben0x539]

This is new, isn't it? Can we get &str -> *u8 too?

[nrc]

I guess it should be *const V

[nrc]

This is not new (afaik, I'm sure I pulled this out of the compiler, but it was a while back).

I don't see a reason not to allow the corresponding string cast. Anyone object?

[ben0x539]

&[V] -> *const V doesn't seem to work, only &[V, .. n] -> *const V.

Also is the mut equivalent intentionally omitted?

[nrc]

Hmm, I probably shouldn't allow casts from &[V] since that is a fat pointer, better to use a function for that. And I guess the same goes for &str to *u8.

[ghost]

How does this interact with raw pointers that denote arrays, like *mut u8 almost always does?

[nrc]

This only allows casts TO *mut T, so I don't think there is an interaction - unless I am missing something?

[ghost]

If I pass a &mut u8 to copy_memory() that is not an array, will it silently cause a buffer overflow?

[huonw]

It won't be a buffer overrun if the length is less than or equal to 1; it's trivial to get a buffer overrun with copy_memory even with a real array, by just passing a length greater than the length of the array.

Also, note that we currently support this &mut to *mut coercion; I don't think it has caused too many problems in practice.

[bstrie]

Is this the opportunity to discuss possibly allowing numeric types to implicitly coerce when there's no loss of precision, e.g. u8 -> u32? I'm not necessarily advocating for it myself, but it has been requested in the past.

[nrc]

@bstrie I think that is a big enough change that it deserves its own RFC

[comex]

I think it would be better to ban such implementations than ignore them.

[nrc]

That is a reasonable alternative. It would require an ad-hoc check in the type checker though

[comex]

What is the difference between this and t as *const U?

Alternately, can this be part of the Unsize trait?

[nrc]

t as *const U would allow more conversions than the intrinsic would. E.g., numeric conversions.

[Kimundi]

Does this make coercion an special case of casts? Eg, is is true that with the changes every implicit coercion can also be written as an explicit cast?

[nodakai]

Will generic integer literals be covered by this RFC? (Perhaps they aren't technically coercion...) I have a little frustration about generic literals with minus sign:

fn main() {
    for x in std::iter::range_step(3u32, 0, -1) {
        println!("{}", x);
    }
}

I don't like -1 silently evaluates to some 4 billion of type u32.

[ben0x539]

@nodakai fwiw that's unrelated to generics, a plain let x: u32 = -1; already silently evaluates to upwards of 4 billion. I don't think it's a coercion, it's just a legal value of unsigned integer literals.

[nodakai]

@ben0x539 When you say "generics," you mean the <T> things, right? I'm talking about those literals which rustc call "generic integer":

fn main() {
    0.f();
}

<anon>:2:7: 2:10 error: type `<generic integer #0>` does not implement any method in scope named `f`

• http://is.gd/8yIej1

[ben0x539]

@nodakai Yeah, I thought you were talking about the <T> in fn range_step<T: ...>. Disregard that, I must have been confused. :)

[abonander]

I would like &T to coerce to T where T is a primitive. It would eliminate so many unnecessary explicit derefs.

[aturon]

Merged. Discussion. Tracking.