Am 26.01.2013 19:20, schrieb Steven Blenkinsop:
You could define an `enum Default<T>= T`
Hm, can you make an example? How will that work? How do I use that?
Michael
On Friday, 25 January 2013, Michael Neumann wrote:
Hi,
I am getting the following error:
msgpack.rs:545:0: 555:1 error: conflicting implementations for a trait
msgpack.rs:545 <http://msgpack.rs:545> pub impl<D: DecoderWithMap,
msgpack.rs:546 <http://msgpack.rs:546> K: serialize::Decodable<D>,
msgpack.rs:547 <http://msgpack.rs:547> V: serialize::Decodable<D>>
~[(K,V)]: serialize::Decodable<D> {
msgpack.rs:548 <http://msgpack.rs:548> static fn decode(&self, d:
&D) -> ~[(K,V)] {
msgpack.rs:549 <http://msgpack.rs:549> do d.read_map |len| {
msgpack.rs:550 <http://msgpack.rs:550> do vec::from_fn(len) |i| {
...
msgpack.rs:539:0: 543:1 note: note conflicting implementation here
msgpack.rs:539 <http://msgpack.rs:539> pub impl<D: DecoderWithMap,
T> T: serialize::Decodable<D> {
msgpack.rs:540 <http://msgpack.rs:540> static fn decode(&self, d:
&D) -> T {
msgpack.rs:541 <http://msgpack.rs:541>
serialize::Decodable::decode(d as &serialize::Decoder)
msgpack.rs:542 <http://msgpack.rs:542> }
msgpack.rs:543 <http://msgpack.rs:543> }
It's obvious that the two trait implementations conflict, as the
one (for T) is
more general as the other (for ~[(K,V)]). Is there anything I can
do to fix it?
I have found this discussion [1] but I see no solution to the problem.
For msgpack, I want to support "maps". They are specially encoded,
so I need a
special Decoder (serialize::Decoder does not support maps in any
way). Above I
tried to extend the serialize::Decoder trait for read_map() and
read_map_elt(),
leading to DecoderWithMap:
pub trait DecoderWithMap : serialize::Decoder {
fn read_map<T>(&self, f: fn(uint) ⟶ T) ⟶ T;
fn read_map_elt<T>(&self, _idx: uint, f: fn() ⟶ T) ⟶ T;
}
Then I tried to implement Decodable for ~[(K,V)] (which I want to
use as a rust
representation as a map; here I'd probably run into problems again as
serializer defines a generic implementation for ~[] and for tuples...
this at least I could solve by using a different type).
Now I would need to reimplement Decodable for any type I use, so I
tried
to use the second generic trait implementation. But this is where
it failed
with a conflict.
Would it be possible to "override" a standard (more generic) trait
implementation,
either implicitly (like C++ is doing) or explictly?
Best,
Michael
[1]: https://github.com/mozilla/rust/issues/3429
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
