Hi Graydon, How does Rust currently represent its' pointers to vectors? Based on what I've seen in the library, it seems that ~[T] and @[T] are plain pointers (with size stored in the pointee), but &[T] is a fat pointer, i.e. a (ptr,len) pair. Is this correct?
On Tue, Apr 30, 2013 at 12:22 PM, Graydon Hoare <gray...@mozilla.com> wrote: > On 30/04/2013 11:26 AM, Gábor Lehel wrote: > > Couldn't this be relaxed? In other words allow dynamically sized `str` >> as a type (and perhaps similarly for other dynamically sized types), but >> prohibit those things specifically which would be problematic, i.e. >> using it in ways that would require knowing its size? >> > > This option was considered at ... great length, a year ago during the > vector-reform conversations. > > https://mail.mozilla.org/**pipermail/rust-dev/2012-April/**001742.html<https://mail.mozilla.org/pipermail/rust-dev/2012-April/001742.html> > https://mail.mozilla.org/**pipermail/rust-dev/2012-April/**001772.html<https://mail.mozilla.org/pipermail/rust-dev/2012-April/001772.html> > https://mail.mozilla.org/**pipermail/rust-dev/2012-June/**001951.html<https://mail.mozilla.org/pipermail/rust-dev/2012-June/001951.html> > https://mail.mozilla.org/**pipermail/rust-dev/2012-July/**002114.html<https://mail.mozilla.org/pipermail/rust-dev/2012-July/002114.html> > > I'm not sure anyone ever reduced those threads to their essence, but > re-reading them I think I can articulate the fundamental difficulty with > what you're suggesting: > > - Any object has a real size. Some sizes are statically known, > some must be discovered dynamically (by reading a size field > or carrying a size value in a (ptr,size) pair) > > - When T is static-size, &T and ~T and @T should be 1-word > pointers. The compiler knows the size. > > - To operate on a vector of statically-unknown size, you > need to get its dynamically-known size from somewhere. > This means pointers to vectors need to carry bounds. > > - So ~[] and @[] and &[] are not the same representation as > ~T, @T and &T in general. They have to have a size stuck > on them somewhere. > > - We want to be able to take sub-slices and have slices that > point to fixed-size vectors in C structs. This means > slices can't have their length in the pointee, and have to be > (ptr,len) pairs. > > So about the only wiggle room away from where we are now is that we might > be able to make ~[] represented by (ptr,len) pairs too, like slices are, > rather than 1 ptr that points to a [len,data...] buffer. But it's not clear > if that would buy us anything. Maybe a bit more genericity in impls, though > I don't know how; Niko might. There might be a bit more room for > improvement here, but it's an _extremely_ constrained space to work in. > > -Graydon > > ______________________________**_________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
