[rust-dev] std::num::pow() is inadequate / language concepts
slabode at aim.com
Sat Jul 26 05:54:24 PDT 2014
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
More information about the Rust-dev