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
[rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Hello!, I'm learning rust and finding myself fighting the language a little and so I could do with a bit of help. In my code completion project I have a function which parses 'use' view items (using libsyntax) and currently returns a vector of vectors of strings representing fully qualified paths (e.g. std::foo::bar). I also have a function which traverses crates and resolves a path to an item source position. It takes the path as a reference to a slice of string references. Here's a stubbed out illustration of the code: pub fn parse_view_item() - VecVec~str { // stub code: let mut vv = Vec::new(); let mut v = Vec::new(); v.push(~std); v.push(~foo); v.push(~bar); vv.push(v); return vv } pub fn search_crate(path : [str]) { // ... } fn main() { let paths = parse_view_item(); for path in paths.iter() { // translate Vec~str to Vecstr let mut v2 = Vec::new(); for item in path.iter() { v2.push(item.as_slice()); } search_crate(v2.as_slice()); } } The issue is that parse_view_item returns owned strings and search_crate() wants borrowed string references, so I end up unpacking each path into a new vector. How should I restructure this code to make things a bit nicer? - can parse_view_item return a narrower interface? - is there a way to avoid the re-packing? - can I do something with iterators to make this nicer? (so far I've favoured using slices over iterators because it makes fn signatures easier on the eye) - will the upcoming string changes make this better? Any pointers much appreciated! Cheers, Phil ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev