On Wed, Jan 23, 2013 at 4:23 AM, Graydon Hoare <[email protected]> wrote:
> The target audience is frustrated C++ developers, same as always. If
> they balk at the syntax for lifetime-bounds on borrowed pointers, then
> yes, we've blown the cognitive budget, and have failed.
[...]
> Thanks for bringing this up. I'm interested to hear others' opinions on
> whether we're past a reasonable limit of comprehensibility. It's a hard
> thing to hear, but better to hear now than later, if true.
As an archetypal "frustrated longtime C++ programmer" I've been
reading about borrowed pointer lifetimes, and following this thread,
with great interest.
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.)
3. I'd politely discourage any conventions of calling things `self`
(such as the main lifetime parameter) which aren't the official
parameter-of-the-same-type-as-the-struct-or-impl. Seeing the blessed,
method-making parameter-name `self` serving multiple purposes within
a single parameter list was very confusing.
4. As an aside (off the specific topic of lifetime syntax, but still
on the more general topic of "intimidation factor" in this thread):
While we're on the topic of (not) overloading `self`, could I propose
introducing `%` as a unary operator for "typeof(variable)"?
If you had a variable `v` of type `T`, then `%v` would be evaluated
to `T` at compile-time, as if `T` had been specified directly. Then
`%self` could be used as a type in traits and `impl`s, instead of
overloading `self` to also mean a type in those particular contexts.
So the example in the tutorial would become:
// In a trait, `self` refers to the self argument;
// `%self` refers to the type implementing the trait
trait Eq {
fn equals(&self, other: &%self) -> bool;
}
5. Back onto the topic of lifetime syntax, whitespace dependency would
be disappointing, so I'm not keen on the `{lifetime}` syntax.
Still a fan of Rust, just wanting very much to see it succeed!
jb
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
