On Tue, Apr 30, 2013 at 9:22 PM, Graydon Hoare <[email protected]> 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/001772.html > https://mail.mozilla.org/pipermail/rust-dev/2012-June/001951.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 > > Thanks for the explanation! That makes a lot of sense. I also just read Niko's blog post, and I'm not sure which thread to reply in (or who to reply to), but I guess I'll do it here. Niko's message here beforehand was kind of expectations-downplaying, but reading the blog post, his proposed scheme seems to allow more or less the same as what I was asking about here (perhaps minus the user-defined dynamically sized types, but that was icing). So *if* the plan ends up working out, then taking the second part of my earlier proposal: > You might also have a rule whereby dereferencing a variable when the > result would be a dynamically-sized type is allowed *if* the result is > immediately borrowed. Then instead of `impl Eq for {@str, ~str, &str}`, > you would have just `impl Eq for str`, and if you want to compare an > ~str you dereference it. Would that work? Would it be a good solution? -- Your ship was destroyed in a monadic eruption.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
