Benjamin Striegel writes:
Sadly, you should really read this subsequent blog post:
http://smallcultfollowing.com/babysteps/blog/2013/01/15/lifetime-notation-r
edux/
Ok, here's another suggestion:
pure fn each</f/>(&self, f: fn(&(&/f/K, &/f/V)) -> bool) { ... }
Lifetimes are always written in slashes. We drop the convention
of using a /self/ lifetime. We require the explicit lifetime
parameter on the function, to minimize magic.
-----------
struct StringReader</s/> {
value: &/s/str,
count: uint
}
struct Foo</f/, T: Reader+Eq> {
value: &/f/T,
count: uint
}
We treat the lifetime as a type parameter, in <...>. We stick to
requiring that it be explicit on the struct and the field, to
minimize magic. I believe this meets Niko's goal of recognizing
lifetimes in the parser.
-------------
struct RefPair</fst/, /snd/, T> {
first: &/fst/T,
second: &/snd/T
}
Multiple lifetime parameters on a struct work fine.
It is clear both to the human reader and to the parser
that /snd/ is another lifetime while T is a type.
-------------
impl StringReader {
fn new</f/>(value: &/f/str) -> StringReader</f/> {
StringReader { value: value, count: 0 }
}
}
fn value</f/>(s: &/f/StringReader</f/>) -> &/f/str {
return s.value;
}
Lots of characters, yes, but the author of the code is
intentionally exercising great control, so I feel it is
worth spelling out what is going on. To my eye, the
consistency of always writing the lifetime in the same
way, /f/, helps tie the mentions of it together. Although
&/f/str is less concise than today's syntax &f/str, I
feel that &/f/str alerts the C++-trained reader that
something special is going on, and perhaps even suggests
that f is a modifier of some kind.
---------------
fn remaining(s: &StringReader) -> uint {
return s.value.len() - s.count;
}
Here, the author has chosen to exercise less control.
We default to scoping the lifetimes across the function
declaration.
---------------
It's a thought!
Dean
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
