How would people feel about something like this?
&<lt> Foo
Foo<<>
It's somewhat inconsistent in that lifetime names do not always begin
with `&` , but I think it retains the "modifier feeling" without
introducing any ambiguities. Another option might be `&<<> Foo` but
that feels like &-overload to me!
Niko
Dean Thompson wrote:
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
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
