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

Christoph Husse thesaint1987 at googlemail.com
Fri Jul 25 09:47:01 PDT 2014


> 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