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,
Thank you for the answers.
2. How to allocate a mutable managed vector dynamically?
I can create an owned vector with: let a = vec::from_elem(..);
I can create a managed vector with: let a = at_vec::from_elem(..);
You cannot. Because the elements of a managed vector are stored inline
On 22/01/2013 9:25 AM, Sami Nopanen wrote:
And in both cases, the sizes would not be known until runtime, so they
could not be represented as [type * cnt]. In both cases, growing the
vector is of no importance.
Oh, I think perhaps Niko overestimated what you were asking for. One
can't create
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
And in both cases, the sizes would not be known until runtime, so they
could not be represented as [type * cnt]. In both cases, growing the
vector is of no importance.
Oh, I think perhaps Niko overestimated what you were asking for. One
can't create a _resizable_ @[], due to the managed
On 1/22/13 10:37 AM, Sami Nopanen wrote:
Anyway, this brings me to yet another question/concern regarding mutable
managed vectors:
I was reading pcwaltons blog regarding the new borrow checker rules. It
mentions that for managed mutable boxes, attempting to mutate will go
through runtime checks
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.
Hi,
I'm trying to get my head around lifetime parameters. I think I mostly get
them, for the simple
cases anyway, but there are couple of examples that are leaving me confused.
Copied some of the example code here from
http://smallcultfollowing.com/babysteps/blog/2012/12/30/lifetime-notation/:
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
If all that you want is the ability to mutate the elements of the
vector, that should be possible. It may be that the requisite library
support is missing, however, I'm not really certain.
Niko
Sami Nopanen wrote:
Thank you for the answers.
2. How to allocate a mutable managed vector
16 matches
Mail list logo
