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
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
