This solution works well ! I think that's a nice enough workaround for
now as I won't spread it that much in my code.
Now I understand why there's a restriction on trait types (though I
thought at the beginning it was an argument type mismatch), I'm looking
forward for a cleaner solution :)
Thanks a lot for your answer.
On 23/05/2013 20:35, Graydon Hoare wrote:
On 21/05/2013 4:50 AM, Vincent O. wrote:
The issue is the same with owned boxes. Is it the intended behavior ? in
this case, is there any workaround ?
You're running into one of the motivations for Niko's work on trying
to unify our treatment of unknown-sized types:
http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/
Essentially: at the moment, a trait-name used as a type is of unknown
size -- each implementation has a different size -- so we disallow
referring to it as a type _at all_ in "type context" such as the T in
ptr_eq<T>, requiring you to write a known-size type there, such as
@Trait or ~Trait or &Trait. This also comes up with 'str' and '[]' not
being types, only @str, &str and ~str (or @[], ~[] and &[]).
The more-complete solution will involve a reorganization of how
unknown-size types are classified. It's planned work, just not done yet.
In the meantime, I suspect your best workaround for what you're trying
to do is ... somewhat awful, as it relies on the fact (that I happen
to know!) that a @Trait is a 2-word "fat pointer":
unsafe {
let a : (*u8,*u8) = cast::transmute(x);
let b : (*u8,*u8) = cast::transmute(y);
x == y
}
This is obviously an awful "solution", but if you're blocked on it, it
should work for now.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
