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:
'ltT
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
Dean Thompson wrote:
Niko has indicated that the sequences like this:
Some(ref value) = {
let value: self/V = value;
are working around a current bug in ref. The let should be unnecessary.
Hello,
I just wanted to note that as of a recent push, the bug (issue
Hi,
You are interpreting it correctly. I don't have time at the moment to
write up an example where multiple independent lifetime parameters would
be required, but it is certainly true that this would be very unusual.
In any case, I have several examples that require two lifetime
Thanks for the clarification. I would be interested to read more
blog posts about further details of this topic.
jb
On Sun, Jan 27, 2013 at 4:46 AM, Niko Matsakis n...@alum.mit.edu wrote:
Hi,
You are interpreting it correctly. I don't have time at the moment to write
up an example where
James Boyden wrote:
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.)
We
.
Dean
From: Alexander Kjeldaas alexander.kjeld...@gmail.com
Date: Thursday, January 24, 2013 2:10 AM
To: Graydon Hoare gray...@mozilla.com
Cc: rust-dev@mozilla.org
Subject: Re: [rust-dev] intimidation factor vs target audience
On Tue, Jan 22, 2013 at 6:23 PM, Graydon Hoare gray
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
How would people feel about something like this?
lt Foo
Foolt
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 `lt Foo` but
that feels like -overload
Dean Thompson wrote:
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.)
I like this idea too,
: rust-dev@mozilla.org
Subject: Re: [rust-dev] intimidation factor vs target audience
Dean Thompson wrote:
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
+1 for the 'lt syntax, it's the first suggestion that I haven't found
difficult to visually parse.
Also it's easier to distinguish from other constructs, since it's not
overloading another common symbol.
I also think the `.lt` option is pretty (actually more so, personally), but
could see the dot
Niko Matsakis wrote:
It's a tough balancing act. Sigils are bad but then if things are too
concrete that's bad too.
Re-reading this mail, I'm not sure if I interpreted your e-mail
correctly. I think I was responding as much to thoughts in my own head
as to what you wrote. What I meant to
I am new to Rust, but quite excited about it. I have read most of the
docs
carefully.
I'm looking at some code that Niko Matsakis updated in
https://github.com/stevej/rustled/commits/master/red_black_tree.rs
pure fn each(self, f: fn((self/K, self/V)) - bool) {
match *self {
Leaf =
Le 22/01/2013 15:55, Dean Thompson a écrit :
(...)
Who is our target audience for Rust? Graydon has said it is
frustrated C++ developers, but how sophisticated and how brave
are we thinking they will be?
Je pense que c'est une question de coût/bénéfice. Compte-tenu du coût
d'apprentissage d'un
Le 22/01/2013 17:16, David Bruant a écrit :
Le 22/01/2013 15:55, Dean Thompson a écrit :
(...)
Who is our target audience for Rust? Graydon has said it is
frustrated C++ developers, but how sophisticated and how brave
are we thinking they will be?
Je pense que c'est une question de
I'm in a similar position to Dean, being new to the language but have
studied the docs quite a bit. I have to agree that the sample he posted is
rather intimidating.
There are a few things about it:
I find the syntax for lifetimes to be quite hard to get used to since it
overloads the operator to
On 22/01/2013 6:55 AM, Dean Thompson wrote:
I'm looking at some code that Niko Matsakis updated in
https://github.com/stevej/rustled/commits/master/red_black_tree.rs
pure fn each(self, f: fn((self/K, self/V)) - bool) {
match *self {
Leaf = (),
Tree(_, ref left, ref key,
I think this is a very important question. Rust is certainly betting
that programmers are willing to learn new concepts and tools. I don't
think anyone will be able to say for certain if this bet will pay off.
Any time that we talk about introducing a new language feature, though,
you can be
Looking at Niko's blog post
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/
We do, to my eye, get a huge improvement if we both tweak the notation and
also augment the ref deconstruction syntax to indicate the resulting
pointer
timeline.
Doing this with Niko's
On Tue, Jan 22, 2013 at 8:01 PM, Dean Thompson
deansherthomp...@gmail.com wrote:
FWIW, Niko's ${foo}bar notation helps my mental parser a great deal,
because it
makes foo look like a modifier to me. When I see foo/bar, my mind fights
to make
it a pointer to foo with a strange trailing bar.
Sadly, you should really read this subsequent blog post:
http://smallcultfollowing.com/babysteps/blog/2013/01/15/lifetime-notation-redux/
It turns out that this syntax is ambiguous without introducing a whitespace
dependency. I think it might still be worth it, but I know that a lot of
people
Jake Kerr wrote:
I find the syntax for lifetimes to be quite hard to get used to since
it overloads the operator to mean something different, and because
the convention seems to be to name the lifetime 'self' inside methods,
which overloads that meaning as well. So now just in the method
22 matches
Mail list logo
