On Wed, May 01, 2013 at 11:49:10AM -0700, Graydon Hoare wrote:
> 1. Why _exactly_ (if it's possible to reconstruct) did this factoring
> not work last time, and what has changed since?
AFAIK we never looked deeply into changing the representation of ~[]
and @[] such that they are represented by a pair rather than a single
pointer. In fact, I originally had it as an explicit goal that ~T for
any T was always a pointer, whereas in this proposal, ~T may be a
single pointer (for sized types) or a pair (for unsized types).
In some of my original proposals I also considered a new kind (what I
called `Sized`) to be non-tenable, so I had some severe limitations on
what you could do with an unsized type, which made them kind of
useless. With the benefit of hindsight, I am of the opinion that
having a `Sized` kind is certainly no *more* confusing than the
current non-compositionality of `~[T]`, and it enables more programs
to boot.
It is a bit unclear how often we will need to use `Sized` in practice.
I argued that a lot of code may not need it, becaues it is implied by
Copy and Clone, but certainly a fair amount will. For example, to
define a standard `map` function over vectors, one would probably
write:
fn map<A:Sized,B:Sized>(v: &[A], f: &fn(&A) -> B) -> ~[B] { ... }
Here the kind on `A` is needed because `A` appears inside `&[A]`, and
you can only have slices of sized types; the kind on `B` is needed
because a `B` is returned by `f` and because it appears within a
vector on the RHS.
> 2. What ballpark amount-of-effort do you think the work entails in
> implementation, and how much do you think it will perturb code?
> It _looks_ to me like .. relatively little on both counts, but it's
> hard to know.
It seems like a relatively straightforward change, actually, but it is
somewhat...extensive. The representation of types within the compiler
will want to change, which will trickle through various parts of the
code, and we'll have to update trans of course (but that's probably
the easy part). One tricky part might be dealing with the various bits
of unsafe code that think they know what the representation of a ~[T]
is, but I imagine we'll find most of those crashes pretty quickly.
> 3. Are any capabilities lost? I don't see any, but I'm a little
> slow on the implications, often. It seems like maybe the GC will
> no longer be able to track sizes by looking in pointees, but
> that's not so bad; there's a digital trie that already covers
> that.
A very good question. I don't think any capabilities are lost from an
expressiveness point-of-view. I hadn't thought about the implications
for garbage collection. I think that all the information that the GC
could need is still present, but it has moved around, and the new
approach would be somewhat less amenable to a conservative
scan. Whereas before everything you needed was present in the `@[T]`
box, in the new world, the length of the array would be found next to
the pointer that led you to the `@[T]` box in the first place. And of
course in a conservative GC you can't be sure that it really was a
pointer and not some random int, so you can't trust that. So we'd have
to find a way to stash the data somewhere else to handle that case,
perhaps in a side-table as you suggest---or else we could duplicate
the information in the GC header, taking the place of the ref count.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
