I believe you need to specify, when declaring foo_generic, that your type T has
the Ord trait (i.e. that objects of type T can be ordered, which is necessary
in order for them to be sorted.) I think the way to do that is
fn foo_generic...
When I test this, I have to 'use cmp::Ord;' in order to
Hi,
I'm not sure it is an defect or failure to fully understand from my side. I'd
like to sort an array. Unfortunately, it is not easy to understand which sort
function should be used, but looks like quick_sort3 is good enough.
Than:
1 extern mod std;
2 use std::sort::*;
3
4 fn foo_g
Wow, interesting. Another bug! Actually, I just remembered that `ref`
bindings in `let` are still broken...I have a pending patch to fix that,
maybe I should go dust if off and see if I can finish it up. The way we
would *really* write this today is as follows:
match *self {
(re
Is this a good place to request comments on a (really horrible) first
Rust program?
https://github.com/tmmcguire/rust-toys/blob/master/mk_anadict.rs
For inspiration (and because I have no actual creativity of my own), I
picked up
http://www.jeffknupp.com/blog/2013/01/04/creating-and-optimizing-a-
That doesn't work. It triggers this error:
test2.rs:8:25: 8:30 error: moving out of dereference of immutable & pointer
test2.rs:8 let (ref a, _) = *self;
^
On Sat, Feb 2, 2013 at 6:21 AM, Niko Matsakis wrote:
> Interesting! I'm surprised to see
Niko Matsakis wrote:
Basically what I'm getting at here is that both *freezable* and
*persistent* maps share the property that they *act like immutable
values*. This is true *even though* freezable maps are modified
in-place, because *at the time of modification* no aliases exist, so
who's
Erick Tryzelaar wrote:
Well, we need the MutableMap-style traits, but we could fold the
ImmutableMap-style "insert into a copy" methods to Map. I don't think
we can rely on "&mut self" helping us out because it could be a source
of bugs. For example, if w forget a hashmap is currently immutab
Interesting! I'm surprised to see that... anyway, try this:
```
let (ref a, _) = *self;
a
```
That's how we normally write it. It might workaround the bug (if not,
I'd like to know!)
Niko
Alexander Stavonin wrote:
Looks like I'd like to do something extremely difficult %)
7 impl(T, T
On 2/2/13 4:50 AM, Michael Neumann wrote:
Ultimately we never often want a stack to be increased in size as this
seems to be a quite expensive operation. Calling a function that crosses
stack space
boundaries (i.e. when it has to alloc new stack space) inside a loop
might severly affect performan
Am 02.02.2013 10:16, schrieb Patrick Walton:
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fail(); }
do reserve_stack(Tiny) {... }
do reserve
On 02/02/2013 01:16 AM, Patrick Walton wrote:
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fail(); }
do reserve_stack(Tiny) {... }
do reserv
On 02/02/2013 01:49 AM, Brian Anderson wrote:
On 02/02/2013 01:16 AM, Patrick Walton wrote:
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fa
On 02/02/2013 01:16 AM, Patrick Walton wrote:
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fail(); }
do reserve_stack(Tiny) {... }
do reserv
On 2/1/13 11:02 PM, Brian Anderson wrote:
In the library we add this sort of function that simply guarantee that
the closure has some amount of stack available.
do reserve_stack(Standard) { rust_task_fail(); }
do reserve_stack(Tiny) {... }
do reserve_stack(Large) { }
do reserve_stack(Size(4096))
14 matches
Mail list logo
