On 13-05-01 04:57 PM, Niko Matsakis wrote:
> 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).
Ok. Makes sense.
> 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.
Concerning the 'Sized' kind, I wonder if it can ever be implied,
somehow, due to the use of T in [T]. Like it's pretty much mandatory if
you do:
impl <T> foo for [T] {
}
that the <T> there actually be <T:Sized> right? You can't denote the [T]
type for any non-Sized T. Not that I'm really keen on any additional
inference rules that a user needs to remember. Hmm.
>> 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.
Sizes are already tracked in the digital trie since we have to do a
nearest-value-less-than-P search for each possible pointer. So it's not
actually a risk / problem; just makes us a tiny bit more committed to
that structure.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
