Oops, I sent that before I finished editing it. I meant struct StrSlice {start: &u8, length: uint}
On Tue, Mar 25, 2014 at 4:33 PM, Phil Dawes <rustp...@phildawes.net> wrote: > Thanks Huon, that really cleared things up for me. > > Dum question: What's the reason for &str being a special fat pointer as a > language feature rather than just a vanilla struct? E.g. struct StrSlice<T> > {start: &T, length: uint} > > (I suppose this question also applies to &[T]) > > > > On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson <dbau...@gmail.com> wrote: > >> It would be necessary (but not sufficient*) for them to have the same >> in-memory representation, and currently ~str and &str don't. >> >> ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a >> vector with the length and capacity stored inline, i.e. one word; &str is >> just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along >> with the length of that chunk, i.e. two words. >> >> >> (*E.g. std::cell::Cell<uint> and uint have the same in-memory >> representation, but coercing a &[uint] to a &[Cell<uint>] is a very bad >> idea... when it would theoretically be possible relates to subtyping/type >> variance.) >> >> Huon >> >> >> On 24/03/14 17:36, Phil Dawes wrote: >> >> To complete my understanding: is there a reason a 'sufficiently smart >> compiler' in the future couldn't do this conversion implicitly? >> >> I.e. if a function takes a borrowed reference to a container of >> pointers, could the compiler ignore what type of pointers they are (because >> they won't be going out of scope)? >> >> Thanks, >> >> Phil >> >> >> On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton <pcwal...@mozilla.com>wrote: >> >>> On 3/23/14 12:11 AM, Phil Dawes wrote: >>> >>>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton <pcwal...@mozilla.com >>>> <mailto:pcwal...@mozilla.com>> wrote: >>>> >>>> Why not change the signature of `search_crate` to take `~str`? >>>> >>>> Patrick >>>> >>>> >>>> Hi Patrick, >>>> >>>> The main reason I haven't done this is that it is already used from a >>>> bunch of places where a path is &[&str] as the result of an earlier >>>> split_str("::") >>>> e.g. >>>> let path : ~[&str] = s.split_str("::").collect(); >>>> ... >>>> search_crate(path); >>>> >>> >>> Ah, I see. Well, in that case you can make a trait (say, `String`), >>> which implements a method `.as_str()` that returns an `&str`, and have that >>> trait implemented by both `&str` and `~str`. (IIRC the standard library may >>> have such a trait already, for `Path`?) >>> >>> You can then write: >>> >>> fn search_crate<T:String>(x: &[T]) { >>> ... >>> for string in x.iter() { >>> ... string.as_str() ... >>> } >>> } >>> >>> And the function will be callable with both `&str` and `~str`. Again, I >>> think the standard library has such a trait implemented already, for this >>> use case. >>> >>> Patrick >>> >>> >> >> >> _______________________________________________ >> Rust-dev mailing >> listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev