Investigate representing slices with 3 words, just like vectors

[nikomatsakis]

Assuming #8981 is completed (which it looks like it will be), I think we should consider representing slices using 3 words. The goal would be to have an invariant that every instance of the type ~T has the same representation as &T, for all T (in a DST world, T includes types like [U]).

This would simplify trans, but it would also enable us to write a function like borrow_all:

fn borrow_all<'a,T>(x: &'a [~T]) -> &'a [&'a T] { unsafe { transmute(x) } }

The main sticking point is that it would require an extra unused word in slices that takes the place of "capacity" (aka "alloc") for normal vectors. It's unclear what performance impact this would have and presumably merits some investigation.

I envisioned this "deep borrowing" as explicit, though it's conceivable we could integrate this into coercion. But in general I sort of want to remove autocoercion wherever possible.

[nikomatsakis]

cc @thestinger @cmr @pcwalton @pnkfelix

[nikomatsakis]

Going further, I am now thinking we should guarantee that ~T, &T, and *T have a "binary compatible" representation for all T. Making *T share a representation with ~T and friends seems like it might help to address issues around creating values like Rc<[T]>. This would also simplify trans and transmuting.

[emberian]

If *T is 3 words, isn't that going to massively break FFI?

On Sat, Nov 9, 2013 at 2:35 PM, Niko Matsakis [email protected]:

Going further, I am now thinking we should guarantee that ~T, &T, and *Thave a "binary compatible" representation for all
T. Making *T share a representation with ~T and friends seems like it
might help to address issues around creating values like Rc<[T]>. This
would also simplify trans and transmuting.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10295#issuecomment-28134965
.

[glaebhoerl]

IIUC *T would be 3 words iff T is a DST, which aren't a thing outside of Rust anyways.

[nikomatsakis]

If *T is 3 words, isn't that going to massively break FFI?

No, because it would only be 3 words for types like *[T]. In C,
there is no comparable type. The closest is *T and a (separate)
integer, I guess.

Niko

[huonw]

How would this interact with trait objects, e.g. given

trait Foo {}

impl Foo for [int] {}
impl Foo for int {}

fn main() {
     let v = (&[1i,2]) as &Foo;
     let w = &1i as &Foo;
}

wouldn't v have a different size to w, since the underlying & pointers are different sizes (so the characterisation of <sigil>Trait as (*vtable, <sigil>SelfType) would break down)?

[Kimundi]

Afaik, without making trait objects take always 4 words, you just wouldn't be able to make such a trait object (such as is the case today)

[nikomatsakis]

I have been assuming that trait objects can never hide a dynamically sized type in any case. In other words, even if you implement trait Trait for [U], you could not case ~[U] to ~Trait (for precisely this reason -- the whole point of Trait objects is to hide the type, so if we must know the type to know how big the pointer is, that doesn't work out so well. I suppose making trait objects 4 words might be enough, though even that doesn't work out if you have something like impl Trait2 for Trait and you try to cast a ~Trait as a ~Trait2.

[pnkfelix]

cc me

[treeman]

Triage bump, carry on.

[nikomatsakis]

I...think this is basically a settled question now.