> 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 ;). _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
