The problem there is that `@Field` is not a type, because you haven't
specified the value for the generic constraint T. That is, the
pertinent trait object would be something like `@Field<int>`. It's not
possible to have a field without the type being specified; that is,
`get_fields()` can only be designed to return fields of one type
(think of it this way—what will the type checker think of the value of
`model.get_fields()[0].get()`? It's got to be exactly one type, but
it's not possible to infer it).
You'd need to deal with something like std::any::Any to achieve what
it looks likely that you're trying to do. Because I wouldn't encourage
designing something in that way as a starting point, I won't just now
give you code covering how you would implement such a thing; see if
it's possible for you to design it in such a way that this constraint
doesn't cause you trouble. Using enums instead of traits is one way
that can often—though certainly not always—get around this problem.
One final note—avoid using @-boxes if possible; is it possible for you
to give owned pointers or references?
On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski
<andres.osin...@gmail.com> wrote:
> Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
> library to manage some common business object behavior.
>
> trait Field<T> {
> fn name() -> ~str;
> fn get_validators() -> ~[&Validator<T>];
> fn get(&self) -> T;
> fn is_valid(&self) -> bool;
> }
>
> trait Model {
> fn get_fields(&self) -> ~[@Field];
> fn validate(&self) -> Option<HashMap<~str, ~[FieldError]>> {
> }
>
> The code fails with the following compiler error:
>
> models.rs:80:35: 80:40 error: wrong number of type arguments: expected 1 but
> found 0
> models.rs:80 fn get_fields(&self) -> ~[@Field];
>
> The reason for the get_fields() method is to return a list of heterogenous
> trait-upcasted objects, and for each of them I'd be invoking the is_valid()
> method.
>
> I would understand that the compiler may not understand the notion of trait
> return types (which would make sense) but I'd be interested to know whether
> this is a bug or a design limitation, and in the second case, whether
> there's a sensible alternative.
>
> Thanks
>
> --
> Andrés Osinski
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
