Andres (cc'ing rust-dev)-
An initial question, since I'm not clear on one thing:
What is your goal in proposing this change?
That is, is your primary concern that you dislike writing either method
invocations or method definitions? Or are you concerned about the
ability of the compiler to optimize the generated code if one uses
methods instead of struct fields?
----
Justifications for why traits should be expressed in terms of associated
methods, not associated fields (and thus why Rust does things this way):
1.) Method definitions are strictly more general than fields, in terms
of allowing other implementations to dynamically compute the value, read
it from a database, from an input stream, etc). I assume you already
are aware of this, and just want to know why we don't provide special
handling for Trait designers willing to rule out such generality up-front.
2.) Associated struct-fields would either disallow mixing traits whose
names collide, or would require extending the `impl` item syntax with a
struct-field renaming feature.
Elaboration of point 2:
Traits are designed to be mixed together; the language should discourage
patterns that make mixing traits on a single type difficult.
The fields of a struct are written down with the `struct` definition.
The associated methods for an implementation are written down with the
`impl` item.
If two traits require the same kind of associated state, right now you
would give them identical method names, and the one struct could
implement both traits (i.e. mixing them) with no ambiguity.
If traits were to define struct names, to get the same amount of
generality we would need to provide some way to map the field name of
the struct to the name expected by the trait within `impl` items. But
why do that? A method definition is a perfectly reasonable way to
express this.
----
Concrete illustration of point 2 above: How would you express the below
in your proposal, assuming that *both* T1 and T2 are revised to require
`state` to be a member field rather than a method?
```rust
trait T1 { fn state(&self) -> int; }
trait T2 { fn state(&self) -> int; }
struct one_int { state: int }
struct two_ints { state: int, state2: int }
impl T1 for one_int { fn state(&self) -> int { self.state } }
impl T2 for one_int { fn state(&self) -> int { self.state } }
impl T1 for two_ints { fn state(&self) -> int { self.state } }
impl T2 for two_ints { fn state(&self) -> int { self.state2 } }
```
----
Again, to be clear: I'm not saying its impossible to express the example
above via hypothetical Traits with fields. But I think it would add
unnecessary complexity (e.g. extensions to `impl` item syntax). So
that's why I wanted to know what the driving motivation here is.
If the motivation is concern over syntactic overhead: method invocations
vs field deference seems trivial. The method definitions are more
annoying boilerplate code, but I imagine that one could write an easy
macro_rules! for the common case where the Trait method name is the same
as the struct field name.
If the motivation is concern over the quality of the generated code: I
assume that LLVM does a good job inlining these things. (If I'm wrong
about that, I'd like to know.)
Cheers,
-Felix
On 20/09/2013 13:02, Andres Osinski wrote:
Hi all, I have a question which I'm sure must have already been
discussed and dealt with, but I wanted to understand the design
rationale:
A lot of trait-level functionality would be enhanced if a trait could
specify members to be included in the struct which implements the
trait. This can be solved in practice by wrapping member access in
accessor methods, but I fail to see why that would be preferable.
The reason I'm asking is because I'm trying to design data structures
which contain a couple of arrays, and I wanted to define the trait by
not only a set of supported operations but by the existence of both
arrays so that a default method could deal with any struct which
implements the trait, instead of having to define for every struct an
accessor method for each structure and then have to call the accessors
in the trait to do anything.
Thanks
--
Andrés Osinski
http://www.andresosinski.com.ar/
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.com
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
