On 1/23/13 1:03 PM, "Niko Matsakis" <[email protected]> wrote:
>How would people feel about something like this? > >&<lt> Foo > Foo<<> > I'm ok with that. Personally, though, I find myself increasingly attracted to the idea of having a consistent notation for writing a lifetime everywhere one appears, independently of the & symbol. (/lt/ is the only such notation I've found yet that seems reasonable.) Consider, for example, how the documentation would read: A lifetime name is written as /name/. The & operator can be followed by a lifetime name. The name of the item can be followed by angle brackets containing a list of lifetime names and type parameters. It strikes me as very easy for the programmer to learn to see /foo/ and at least go "hmm ... how is that lifetime being used?" With the "permutations of &" approach, you can never make such definitive statements. Instead, you are always saying things like this: The name of the item can be followed by a set of angle brackets with a list of lifetime names (which are marked with a & prefix) and type parameters. The & operator can be followed by a lifetime name in angle brackets... Also, with "permutations of &", every time there's a new need to refer to a lifetime name, we would have to come up with a new way of representing it. For example, if ref needed an explicit lifetime name, we'd have to decide where to put the & marker. There are some corresponding decisions to make in my approach, but somehow it just seems more direct to me. But then, that's me :-) Dean On 1/23/13 1:03 PM, "Niko Matsakis" <[email protected]> wrote: >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 >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
