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

Christoph Husse thesaint1987 at googlemail.com
Fri Jul 25 09:53:58 PDT 2014

Sorry... I meant a^8 xD...

And overlaoding is not a great concept in general, IMO.
What Rust could do is copy template specialization. So that I can say:

pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T; //
uses the exponential trick

pub fn pow<i64>(mut base: i64, mut exp: uint) -> i64; // uses some
cool processor features if available

pub fn pow<BigInt>(mut base: &BigInt, mut exp: uint) -> BigInt; //
uses some mighty algorithm that is not naive ;)

This avoids the horrible confusing of having functions acting totally
different depending on parameter count. Of course there should still
be the requirement in place that all specializations fulfill the
original template contraints. And in the best case also need to
fullfill some generic unitests that give a specification to ensure
that the user is not confused by this sort of "overloading".

On Fri, Jul 25, 2014 at 6:47 PM, Christoph Husse
<thesaint1987 at googlemail.com> wrote:
>> I gave up at all. (I'm doing software design and implementation since
>> more than 30 years, and I never accept compromises, this is the way
>> how to develop magnificient software).
> Hum, I would almost strongly disagree. I would even go as far as
> saying that you won't develop any kind of reasonable software outside
> of academic environments without making a whole fairytale of
> compromises. In fact, everything is a compromise. Besides that, giving
> up just because you can't overload functions, in a language that is
> still evolving also sounds rather strange. More legit would be to
> mention the issue, ask how the designers of the language would solve
> it and maybe suggest what could be improved etc...
>> the big integer libary because I cannot specialize std::num::pow(). There is
>> no way to proceed with a proper design.
> Well, I guess you did nothing but C++ in the last 30 years then?
> Because I can't recall many languages that would allow this sort of
> thing. How would C# and Java's Math::Pow() would work out in this
> case? How would it work out in C? How would it work out in Python,
> JavaScript, etc... the list is ... quite long.
> The question is always about compromise. Shall rust include a language
> feature to make some things easier for the sake of introducing tons of
> problems as well?
> Java is about the least expressive language we have at the time
> (appears a bit like the greatest common denominator of all imperative
> languages) and I would say only few people are out there who would say
> that you can't do proper software design with it. It might not be a
> concise and pleasing as "GOOD C++ design is", but then again "GOOD C++
> design" is very hard to archieve and thus begs the questions if it is
> even worth it to make a language that complicated so that magnificient
> (academic) design is possible at the cost of making the average
> (industrial) design horrible.
>> pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T;
> I agree this definition appears to be very strange to me. In more than
> one way. First it implies that the existing implementation works by
> somehow multiplying types with the expontential trick " a * a = b, b *
> b = c, c * c = a^6" etc...
> This is an unacceptable restriction for me, as this kind of evaluation
> might not be the best in many cases and we are talking about a
> standard library function after all. It should always allow the BEST
> implementation, not just some implementation.
> Here we clearly need a better concept. And this concept needs to be
> designed & defined. And you could start by doing this, instead of just
> giving up ;).

More information about the Rust-dev mailing list