On 07/25/2014 01:04 PM, Patrick Walton wrote:
I don't think we should be trying to solve it.
I don't agree. If this problem is truly appreciated, then you have to conclude that completely generic code is not possible in Rust, which means that Rust should not bless particular generic signatures (the operator overloading traits, the iterator trait, maybe a few others I can't think of right now) with special syntax because they can't possibly be efficient in all cases.
While this doesn't matter for the pow function (the alternate function would just have a different path/name), it matters for the special syntaxes. When the Iterator is no longer enough for you (there was a case like this in IRC recently involving mutable windows), then you have to abandon the for loop which is a big syntactic change (right now it works because it is ad-hoc). Similarly, when the operator overloading traits are insufficient, then you have to abandon that sugar as well. One might say "well, don't use those traits then" but that's not what happens in practice. In practice, people want the syntax sugar and therefore are guided into inefficiency. Some of BigNum's operator overloads shouldn't exist because they are so inefficient, and yet they do because people expect BigNum to act (on a syntactic level) just like any other number.
So I think this is a real problem with real solutions that don't require going down the ad-hoc template black hole. Part of the solution has to involve changing how the language syntax sugar works. The other part, however, involves libraries: if the generic functions in libnum expect types to act as built-in types (by requiring T: Mul<T, T> etc), then BigNum should not act like a built in type; alternatively, the generic functions in libnum should be overloadable (via the double-dispatch trick). Maybe there's some other library-based pattern that would work as well.
-SL _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
