On 11/08/2013 09:43 AM, Gaetan wrote:
I agree, I don't understand the syntax here.
Look at the Url class:
pub struct Url {
scheme: ~str,
user: Option<UserInfo>,
host: ~str,
port: Option<~str>,
path: ~str,
query: Query,
fragment: Option<~str>
}
pub type Query = ~[(~str, ~str)];
fn split_char_first(s: &str, c: char) -> (~str, ~str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), ~"");
}
}
Isn't simpler, and easier to read, if we write it
pub struct Url {
scheme: str,
user: Option<UserInfo>,
host: str,
port: Option<str>,
path: str,
query: Query,
fragment: Option<str>
}
pub type Query = [(str, str)];
fn split_char_first(s: &str, c: char) -> (str, str) {
...
if index+mat == len {
return (s.slice(0, index).to_owned(), "");
}
}
KISS !
-----
Gaetan
Sure! I'd strongly support that (exactly the changes you propose).
But I thought the obligation to explicitely specify the pointer type was a
side-effect of the variety of pointer "kinds" in Rust: If in Rust one is to able
to choose which kind of pointer is used, then, well, we must write it down
somewhere somehow, no?
Some of the strings or arrays above (or more generally structured data), may be
shared, referenced from other structured thingies, in which case we'd need a
"non-owned" pointer (probably @). Or do I misunderstand?
Somewhat related but distinct, I thought we could get rid of specifying the
pointer type for function input: seems to be always &, no? Or &mut when changed
inside the func, but the compiler can probably tell that; also, if the param is
not changed, having &mut does not affect the semantics anyway... Or, if pointed
function input is not always & / &mut, systematically, in current Rust code,
could it be anyway, without exaggerated semantic constraint or efficiency loss?
Still related but distinct, what other uses for & (and &mut) than function
input?
Denis
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
