1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
// Copyright 2012 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
// does the second one subsume the first?
// xfail-test
// xfail-fast
// notes on this test case:
// On Thu, Apr 18, 2013 at 6:30 PM, John Clements <clements@brinckerhoff.org> wrote:
// the "issue-2185.rs" test was xfailed with a ref to #2263. Issue #2263 is now fixed, so I tried it again, and after adding some &self parameters, I got this error:
//
// Running /usr/local/bin/rustc:
// issue-2185.rs:24:0: 26:1 error: conflicting implementations for a trait
// issue-2185.rs:24 impl iterable<uint> for &'static fn(&fn(uint)) {
// issue-2185.rs:25 fn iter(&self, blk: &fn(v: uint)) { self( |i| blk(i) ) }
// issue-2185.rs:26 }
// issue-2185.rs:20:0: 22:1 note: note conflicting implementation here
// issue-2185.rs:20 impl<A> iterable<A> for &'static fn(&fn(A)) {
// issue-2185.rs:21 fn iter(&self, blk: &fn(A)) { self(blk); }
// issue-2185.rs:22 }
//
// … so it looks like it's just not possible to implement both the generic iterable<uint> and iterable<A> for the type iterable<uint>. Is it okay if I just remove this test?
//
// but Niko responded:
// think it's fine to remove this test, just because it's old and cruft and not hard to reproduce. *However* it should eventually be possible to implement the same interface for the same type multiple times with different type parameters, it's just that our current trait implementation has accidental limitations.
// so I'm leaving it in.
// actually, it looks like this is related to bug #3429. I'll rename this bug.
// This test had to do with an outdated version of the iterable trait.
// However, the condition it was testing seemed complex enough to
// warrant still having a test, so I inlined the old definitions.
trait iterable<A> {
fn iter(&self, blk: &fn(A));
}
impl<A> iterable<A> for &'static fn(&fn(A)) {
fn iter(&self, blk: &fn(A)) { self(blk); }
}
impl iterable<uint> for &'static fn(&fn(uint)) {
fn iter(&self, blk: &fn(v: uint)) { self( |i| blk(i) ) }
}
fn filter<A,IA:iterable<A>>(self: IA,
prd: &'static fn(A) -> bool,
blk: &fn(A)) {
do self.iter |a| {
if prd(a) { blk(a) }
}
}
fn foldl<A,B,IA:iterable<A>>(self: IA, b0: B, blk: &fn(B, A) -> B) -> B {
let mut b = b0;
do self.iter |a| {
b = blk(b, a);
}
b
}
fn range(lo: uint, hi: uint, it: &fn(uint)) {
let mut i = lo;
while i < hi {
it(i);
i += 1u;
}
}
pub fn main() {
let range: &'static fn(&fn(uint)) = |a| range(0u, 1000u, a);
let filt: &'static fn(&fn(v: uint)) = |a| filter(
range,
|&&n: uint| n % 3u != 0u && n % 5u != 0u,
a);
let sum = foldl(filt, 0u, |accum, &&n: uint| accum + n );
printfln!("%u", sum);
}
|
