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 list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
