On Sat, Nov 09, 2013 at 09:46:38AM +1100, Huon Wilson wrote:
> Ah, of course. Presumably this means that `Rc<Trait>` or `Rc<str>`
> would require a separate code-path?
I've been thinking about this somewhat. I'm not sure if this is true.
And in fact while both `Trait` and `str` are "dynamically sized
types", they are not comparable and must be considered separately.
1. The type `Trait` is in fact not a type at all, it's shorthand for a
type that the compiler "forgot" (jargon: an "existential type"). That
is, every Every instance of `Rc<Trait>` in fact began its life as a
`Rc<T>` for some known `T`, and the user "cast away" (pun intended)
the `T` to make an object:
Rc<T> as Rc<Trait>
At runtime, this kind of cast (which, as an aside, I hope will no
longer have to be explicit soon, it's quite tedious) pairs up the
`Rc<T>` with a vtable. So in fact `Rc<Trait>` requires no
"participation" on the part of `Rc<T>`, but we will have to figure out
some niggly details like how the compiler decides what type parameters
can be changed from `T` to `Trait` and so forth.
2. True dynamically sized types like `[T]` and `str` are different,
because they require fat pointers in place of thin ones. Until
recently I was thinking we'd just (for now anyway) prohibit `Rc` and
`Gc` etc from being instantiated with a DST. However, I was thinking
recently that since `Rc<T>` and `Gc<T>` would build on `*T`, perhaps
we can just define `*[T]` and `*str` to be the same sort of fat
pointers, and things will work out rather nicely once everything is
monomorphized. I have to think this over, but it's a promising idea.
There are some complications for `Gc<[T]>`; when one traverses a
pointer to this garbage-collected box, one must be sure to carry along
the length information about the vector. But this doesn't seem
unsolveable.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
