It just occurred to me that the 'lt syntax for lifetimes does (I think) provide an unambiguous way keep the pointed-to type right next to the & sigil:
'lt&T Here, the usual & sigil becomes 'lt&, which taken together is a prefix on the type T. In this notation, there is still a clear distinction between Niko's examples below, which become 'b&T &'b&T I'm not sure whether I like it better or worse than the prevailing alternative &'b&T (with the opposite meaning!) &&'b T I believe it does address James Boyden's goals (below) 2a and 2b, although not 2c, and this issue is orthogonal to 2d. Since I resonate with 2a and 2b myself, I lean toward thinking I like this alternative approach a little better. Dean James Boyden had written: > > For the above reasons, is there any way that the lifetime syntax > could be moved *after* the type? The current proposal of `&'lt Foo` > does address the ambiguity described in point 2b, but not 2a or 2c. > (The `/` sigil itself actually doesn't faze me that much.) Niko Matsakis had written: > We considered this, but it's very hard to mix prefix and postfix notation like > this without ambiguity. Consider: > &&T/b > Is this: > &'b &T > or > &&'b T > > I suppose we could just resolve it arbitrarily, like if-else-if chains. More completely (for reference), James Boyden had written: > For what it's worth, here's my 2 cents: > > 1. Borrowed pointer lifetimes are a very interesting concept. I think > they definitely enrich Rust. However... > > 2. The current syntax of `&lifetime/type` completely threw me when > I first saw it in the wild (before reading up on the topic in the > tutorials). I'm concerned that this could be something that might > push Rust slightly too far towards "obscure academic theory language" > for many C++ programmers. Specifically: > > 2a. I'm used to seeing the pointed-to type right next to the pointer. > I can mentally reverse C++'s `int &p` to `p: &int` without problems, > but having extra line-noise in there seems to stretch my on-the-fly > language-parsing capability beyond its limits -- particularly so when > the identifiers both before and after the `/` look like types, and > there's no whitespace breaks to guide my mental tokeniser. > > 2b. I found the `p: &r/float` syntax especially confusing in that > sometimes, without any prior or intervening warning, the next token > after the borrow-pointer sigil `&` was a lifetime instead of a type > (but of course, not all the time). When you're mentally parsing it, > you don't get any explanation of what you're reading until *after* > you've read those tokens. > > 2c. I care more about the pointed-to type than the lifetime (at least > on my first scan through the function parameters), so I'd strongly > prefer to have the pointed-to type closer to the front, and closer to > the parameter name and pointer sigil (i.e., before the lifetime name). > This has the additional benefit that now all the parameter type info > is together, followed by the lifetime info. > > 2d. `&` means "pointers" or (occasionally) bitwise-AND. Please don't > use it for any other plumbing! (I'm thinking of "Lifetime parameter > designated with &" in the previous notation.) > > > For the above reasons, is there any way that the lifetime syntax > could be moved *after* the type? The current proposal of `&'lt Foo` > does address the ambiguity described in point 2b, but not 2a or 2c. > (The `/` sigil itself actually doesn't faze me that much.) >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev