RFC: Coercible and HasPrefix for Zero Cost Coercions

[gereeter]

This is largely based on (with lots of copied text) @glaebhoerl's proposal in rust-lang/rust#9912, but with a few changes:

• I formalized the idea of "contexts" by using GHC's roles.
• I used this role system to include user-defined pointers and data structures.
• I dropped contravariance for simplicity. This may have been a bad idea, but it's unclear how useful contravariance is.

rendered draft

[lilyball]

Typo ("transparenta ccess").

[lilyball]

Why does it need to be a proper subtype? This would prevent coercing between two types that are considered equivalent. For example, between a newtype and the underlying uint (which is to say, you could define the coercion in one direction, but not the other).

[gereeter]

Good point - I'm not sure why I kept the word proper in there. I'll remove it.

[glaebhoerl]

I think my original intent here with "proper subtype" was just to emphasize the distinction from merely "has prefix". For "strictly fewer inhabitants" I would have said "strict subtype".

[lilyball]

This right here indicates that you are not actually enforcing the "is a proper subtype" rule, because B and A can't both be proper subtypes of each other.

[gereeter]

Fixed.

[lilyball]

Do we actually guarantee the layout of tuples? I didn't think we did. Or at the very least, I would expect RFC 18 to make the layout undefined.

[gereeter]

I'm not exactly certain how this interacts with RFC 18. It probably is reasonable to assume that there isn't any difference between fixed size arrays and tuples (reordering does nothing when the types are the same). However, the tuple prefix rule might have to be dropped, and the first field rule might need an extra keyword. The only one of these I'm truly worried about is the first field rule - the tuple coercions don't seem that useful.

[lilyball]

Reorder definitely does affect it. It may be the same memory layout, but if I coerce (a, b, c) to an array and get [c, b, a] then that's not very helpful.

[huonw]

RFC 18 does not mention tuples, so they currently have defined layout.

[bstrie]

@huonw Which, frankly, seems like a backwards-compatibility hazard at this point. If we decide to make tuple layout unspecified for 1.0, we can always choose to re-specify it later. The opposite is impossible.

[bstrie]

The question is, where would you stick the attribute if you wanted it to be specified? In that case, I'd be inclined to force users to just use structs instead of tuples. But this is stuff for a different RFC.

[glaebhoerl]

I think the particular set of built-in coercion rules is not so important as just having the mechanism. The rules I originally included were a grab bag of whatever I could immediately think of, mainly to illustrate the possibilities. We could have only the most obviously useful and correct rules to begin with, and then add others later in a backwards compatible way, if we want to.

[huonw]

@bstrie I don't disagree, I was just pointing out that the layout isn't (yet) undefined.

Maybe someone should submit a modification to that RFC making tuples also explicitly undefined.

[glaebhoerl]

Huge thanks for taking this up. I'll try to leave a few comments.

[glaebhoerl]

I would hope that all of them are perfectly safe, because otherwise it's a bug! I think you just meant to say that the could compiler could verify their safety under this proposal. :)

[gereeter]

They aren't all safe, and it is a bug: rust-lang/rust#13933. I think there are others, but those are the most blatant.

[glaebhoerl]

Interesting, I've been trying to piece together in my head how these covariant, contravariant, (bivariant, invariant) roles relate to the nominal, representational, and phantom roles of GHC for some time now. (What they all have in common is that they are only consumed by the respective Coercibles.) I'll have to think about this.

[glaebhoerl]

FWIW, I was relating to GHC's implementation here, and I originally thought "here be dragons", that this whole "would only be in scope when ..." business was the least well thought out and well-specified part of the proposal. But since then, I've realized that Rust could do it much more simply and straightforwardly with something like the late RFC PR #10. And unlike GHC, we could actually implement the thing as just a bunch of (incoherent) wired-in impls. The mechanism would simply be that, like all other built-in traits, HasPrefix and Coercible would be automatically derived by the compiler for plain (public-definition) structs and enums (according to the rules above), and would need to be declared/derived by the programmer explicitly for abstract structs and abstract enums. All of the complexity in GHC's implementation is just to work around them having the wrong defaults.

[glaebhoerl]

The inference part could be solved by allowing foo as _ - I think we already have type placeholders, so this would just fall out? The part about expected meaning is the real problem. If someone writes 6.0 as int, they probably don't intend a bitwise reinterpretation.

[glaebhoerl]

(See again RFC PR #10. I'm strongly in favor of properly enforcing abstraction boundaries by default, unlike GHC.)

[cmr]

See also http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/coercible.pdf

[glaebhoerl]

FWIW if I were writing this proposal today, I would go with this naming scheme:

• unsafe fn transmute<T, U>(T) -> U -> unsafe fn unsafe_transmute<T, U>(T) -> U
• trait Coercible<T> -> trait Transmute<T>
• fn coerce<U, T: Coercible<U>>(T) -> U -> fn transmute<U, T: Transmute<U>>(T) -> U

In other words, rename the existing transmute to unsafe_transmute and use Transmute and transmute instead of Coercible and coerce.

This is more consistent with Rust's existing terminology which uses "transmute" to mean the thing we are doing here, and "coerce" to mean something different (not-necessarily-free compiler-inserted casts). It also happens to directly mirror GHC's (quite logical) scheme of unsafeCoerce, Coercible, and coerce, except using the word "transmute" instead of "coerce".

I still don't have a better idea for what to call HasPrefix.

[brson]

Discussed at https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-06-24.md#rfc-pr-91-coerciblehasprefix-httpsgithubcomrust-langrfcspull91-

Ergonomics in general is an area we want to focus on leading up to 1.0, and coercions probably have a role. We're not ready to make any decisions on the subject yet. Closing, but tagging with 'postponed' so it can be referenced later.

[glaebhoerl]

Ergonomics in general is an area we want to focus on leading up to 1.0, and coercions probably have a role.

This is much more about expressiveness, safety and performance than about ergonomics. The name "coercible" was misleading in this context, because Rust uses it to mean something different (see previous comment).

I agree that implementing this is not urgent, just wanted to clarify.

[glaebhoerl]

So... I thought I made a discovery, inspired by an email from Edward Kmett, and then I re-read the RFC, and realized that it already does things exactly the way I was going to suggest, following my "discovery". The discovery was that we can completely avoid the need to have explicit role/variance annotations on type parameters (e.g. struct Foo<covariant T>) by just writing out the equivalent generic Transmute impls instead:

• Instead of struct Foo<bivariant T>: ("bivariant" is another name for "phantom")

  // `Foo` doesn't actually contain a `T`, so we can `transmute` the `T` to any other type
  impl<T, U> Transmute<Foo<U>> for Foo<T> { }
  

• Instead of struct Foo<covariant T>:

  // (Here `Foo` contains `T` only in "positive" positions.)
  // We can `transmute` `Foo<T>` to `Foo<U>` iff we can transmute `T` to `U`, 
  // i.e. if `U` is a "subtype" of `T`.
  impl<U, T: Transmute<U>> Transmute<Foo<U>> for Foo<T> { }
  

• Instead of struct Foo<contravariant T>:

  // `Foo` uses `T` only in "negative" positions, e.g. function parameters,
  //  so this is the reverse of the above.
  impl<U, T: Transmute<U>> Transmute<Foo<T>> for Foo<U> { }
  

• Instead of struct Foo<invariant T>: ("invariant" is another name for "representational")

  // `Foo` uses `T` in both positive and negative positions, 
  // so we can only `transmute` between `Foo<T>` and `Foo<U>` if they're "subtypes"
  // of each other in *both* directions, e.g. if one is a newtype of the other.
  impl<T, U> where T: Transmute<U>, U: Transmute<T> Transmute<Foo<U>> for Foo<T> { }
  

• Instead of struct Foo<T>: (a completely fixed type parameter is also referred to as "nominal")

  // (nothing)
  // This is the case for types which not only use `T`, but also depend
  // in some way on its precise *identity*, as opposed to merely its representation. 
  // A good example is the `K` in `HashMap<K, V>`: you can't allow transmuting
  // it to any other type, because that other type might have a different impl of `Hash`,
  // which would break the internal invariants of the `HashMap`.
  

But, as I mentioned above, the RFC already specifies exactly this:

To declare the roles of each parameter, users must write impls of Coercible that follow the above patterns - each variable must be independent and only bounded by either HasPrefix or Coercible. By default, every parameter is nominal.

So I commend @gereeter's brilliance for realizing this before anyone else.

I think I was mislead by the earlier statement that:

To deal with data structures and pointers, we need to introduce the concept of roles,

which I unthinkingly assumed implied explicit nominal, phantom, and/or representational annotations along the same lines as GHC. Whereas by just writing the equivalent generic Transmute impls instead, I would say that we are avoiding the need to "introduce the concept of roles".

(Which is a very good thing!)

[jsgf]

How does this RFC look through the eyes of 2017 Rust?