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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
