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
