Hello,
While Patrick's advice to avoid @ is good in general, in this case I
think it does not apply. Persistent or purely functional data
structures basically must use @ so that they can share pointers into
their internal nodes. I do hope that when Rust's libraries become more
mature we
On Sat, Dec 15, 2012 at 7:02 PM, Nathan nejuc...@gmail.com wrote:
Also, traverse should probably belong in its own trait.
It seems like traversal over keys *and* values is quite useful,
because it's common for applications to need both, and doing a
separate lookup when a traversal is
Thanks, I started with this definition and implemented BaseIter for my
RBTree.
https://github.com/stevej/rustled/commit/85cf4340eb1c0b985e27a48fe2603e6b75ffcb45
size_hint returns None as I'm not tracking size. I think that's ok? It's
hard to tell from the BaseIter documentation.
On Mon, Dec
On Mon, Dec 17, 2012 at 11:46 AM, Graydon Hoare gray...@mozilla.com wrote:
On 12-12-17 11:28 AM, Graydon Hoare wrote:
On 12-12-14 03:51 PM, Steve Jenson wrote:
I recently ported Matt Might's Scala port of Okasaki's purely functional
red-black tree to Rust and am looking for some feedback.
On 12-12-18 04:56 PM, Steve Jenson wrote:
That's a mutable LLRB tree whereas mine is immutable.
Ah. Good point.
Since the language provides optional mutability, is it a goal to have
both pure functional and mutable versions of common data structures and
traits?
In some sense. Specifically,
On 12-12-17 11:28 AM, Graydon Hoare wrote:
On 12-12-14 03:51 PM, Steve Jenson wrote:
I recently ported Matt Might's Scala port of Okasaki's purely functional
red-black tree to Rust and am looking for some feedback.
https://github.com/stevej/rustled/blob/master/red_black_tree.rs
I've written
Is it important for `traverse` to pass along an option type? Is it
important to inform end users that a key has been deleted? Or is that
implementation specific? If so, I suggest rewriting `traverse` to something
like this (assuming this actually works):
implK, V RBMapK, V: iter::BaseIter(K, V)
Would this trait:
pub trait MapK: Copy Eq Ord, V: Copy {
pure fn get(k: K) - @OptionV;
pure fn put(k: K, v: V) - self;
pure fn delete(k: K) - self;
pure fn traverse(f: fn((K), (@OptionV)));
}
be something that ought to live somewhere in the standard library?
I
On Sat, Dec 15, 2012 at 11:46 AM, Patrick Walton pwal...@mozilla.comwrote:
On 12/15/12 8:58 AM, Benjamin Striegel wrote:
Would this trait:
pub trait MapK: Copy Eq Ord, V: Copy {
pure fn get(k: K) - @OptionV;
pure fn put(k: K, v: V) - self;
pure fn delete(k: K) -
On Sat, Dec 15, 2012 at 4:45 PM, Steve Jenson ste...@fruitless.org wrote:
On Sat, Dec 15, 2012 at 8:58 AM, Benjamin Striegel ben.strie...@gmail.com
wrote:
Would this trait:
pub trait MapK: Copy Eq Ord, V: Copy {
pure fn get(k: K) - @OptionV;
pure fn put(k: K, v: V) -
On 12/15/12 4:38 PM, Steve Jenson wrote:
I could use advice here. Is it possible for me to write a single trait
that can be used by both users that want to use managed boxes and people
who wish otherwise? IOW, what is the best way to abstract away the @sign
in this trait?
It depends on how you
On 12/15/12 7:15 PM, Patrick Walton wrote:
However, if you modify the algorithm to use unique pointers throughout,
then your methods like get() can probably return a borrowed pointer
instead.
To add: For anyone interested in making data structures that don't use
the garbage collector, look at
12 matches
Mail list logo
