[rust-dev] std::num::pow() is inadequate / language concepts

SiegeLordEx 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 
as well.


More information about the Rust-dev mailing list