For the specific issue of exponentiation, you might be interested in https://github.com/rust-lang/rfcs/pull/172
On Fri, Jul 25, 2014 at 9:26 AM, Gregor Cramer <rema...@gmx.net> wrote: > Hi Marijn, > > > > > Firstly, blanket statements like "This makes generic programming > > > impossible" and "it does not allow proper software design" are > > > unneccesary hyperbole, and do not help the discussion in any way. > > > > You're not right, my statement wasn't blanket, it was my result > > after I tried to overwork the big integer library, and I have mentioned > this: > > 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). > > > > > Traits provide a more well-defined, easier to reason about alternative > > > to overloading. They do require the author of an algorithm to decide > > > ahead of time whether this algorithm needs to be specializeable, which > > > I guess C++-style overloading does not. > > > > Yes, the traits are great, I'm impressed, as I said before, and in fact > Rust > > is really great, despite a few facts, otherwise I wouldn't subscribe to > > this mailing list. And my goal is to be constructive, don't worry if I'm > > a bit euphoric, such things happens. Nethertheless, it gave up to overwork > > the big integer libary because I cannot specialize std::num::pow(). There > is > > no way to proceed with a proper design. > > > > > Whether that is a good or a > > > bad thing is debatable, but it is not true that Rust lacks a feature > > > for specialization. > > > > There is a lack in the current language concept, std::num::pow() > > is inadequate due to this language concept, and std::num::pow() is > > only one example for this fact. > > > > I will repeat the problem with signatures. Currently pow() is declared > > as following: > > > > pub fn pow<T: One + Mul<T, T>>(mut base: T, mut exp: uint) -> T; > > > > That't 100% ok. The user will call this function in this way: > > > > pow(a) // a is i32 > > > > Perfect. Now I need a specialized function for BigInt: > > > > [#overload] > > pub fn pow(base: &BigInt, mut exp: uint) -> T; > > > > There's a problem (beside the missing overloading feature): the > > specialized version requires a reference. Same problem if I'm > > calling this function: > > > > pow(&a) // a is BigInt > > > > The user has to know how to call a function, depending on the type. > > But a proper function specialization would be: > > > > [#overload] > > pub fn pow(base: BigInt, mut exp: uint) -> T; > > > > And so the function call is as expected, like with other numeric types: > > > > pow(a) // a is BigInt > > > > But there is now a problem in this function definition, BigInt is given as > > a copy, and this is a software design issue (superfluous memory > allocation). > > And this currently happens if the user is calling std::num::pow() with a > > numeric type like BigInt (apart from other performance penalties in pow()). > > > > That's what I've mentioned that the compiler should decide whether an > > argument is given by reference or by value. In this way the latter approach > > works. And in the case that a function willl modify an argument (in-out > > value), for example: > > > > fn mul_vec(acc : &mut [BigDigit], base: &mut [BigDigit], mut exp:uint) > > > > the call of this function would be: > > > > mul_vec(&a, &b, exp) > > > > This concept will not change, because here it has to be clear that an > argument > > will be changed (furthermore the compiler should give a warning if a > function > > is not changing a mutable argument). I think that this approach is even > > superior to the 'const' concept of C++, and it fit's with the great overall > > concept of Rust (especially with the owner/borrower concept). > > > > I try to show the problems if function specialization (overloading) is not > > supported. A stable software design is problematic. Adding a new module, > > which will use existing function declarations, is impossible in some cases. > > Currently I cannot implement a specialized version of pow() for BigInt, > adding > > a new function for a different numeric type is only a hack, and moving this > > function into a trait is not solving the general problem, because pow() is > > only one example. (Beside: it's not my decision to move pow() into a > trait.) > > > > Cheers, > > Gregor > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
