I think that the deeper and larger language design issue here is that traits in some cases force you to impose on the trait-implementing type some implementation details that should remain hidden in the specification of the trait and should be left to the trait-implementing type to specify.
The high level (of abstraction) description of an expression like: a * b ...is that that it should evaluate to the product of `a` and `b` without modifying neither `a` nor `b`. The manner in which the expression accomplishes this task is an implementation detail. If the expression above evaluates to a function call where `a` and `b` are passed as arguments, then the manner in which the two arguments are passed into such a function is an implementation detail, assuming there are multiple ways in which the arguments could be passed and the function call could still fulfill the high level requirements and guarantees of the expression. For example, POD `a` and `b` could be passed to such a product evaluating function in multiple ways, namely by value and by reference. If the definition of `Mul` trait specifies the exact manner in which the arguments must be passed to this product evaluating function, then the trait is revealing and imposing an implementation detail that should be left to the judgement of the type which implements such trait. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
