Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
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 StrSliceT {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::Celluint and uint have the same in-memory representation, but coercing a [uint] to a [Celluint] 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.comwrote: 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_crateT: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
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
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 StrSliceT {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::Celluint and uint have the same in-memory representation, but coercing a [uint] to a [Celluint] 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.comwrote: 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_crateT: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
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
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.comwrote: 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_crateT: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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
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::Celluint and uint have the same in-memory representation, but coercing a [uint] to a [Celluint] 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 mailto: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 mailto: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_crateT: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 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
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
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_crateT: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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
On 23/03/14 18:14, Patrick Walton 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_crateT: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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev std::str::Str http://static.rust-lang.org/doc/master/std/str/trait.Str.html Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Great, thanks Patrick + Huon On Sun, Mar 23, 2014 at 7:47 AM, Huon Wilson dbau...@gmail.com wrote: On 23/03/14 18:14, Patrick Walton 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_crateT: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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev std::str::Str http://static.rust-lang.org/doc/master/std/str/trait.Str. html Huon ___ 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