Hi Patrick,
If the signature is wrong and we mistakenly freeze it, we can just introduce
a new function with a different name.
But this is a severe design issue, to introduce new function names. This makes
generic programming impossible. Now the user has to distinguish between
the types, but
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
Did I miss a point in this thread where using a typeclass/trait to
implement exponentiation was dismissed?
This function could be changed to:
fn powT: HasPow(base: T, exp: uint) - T { base.pow(exp) }
trait HasPow {
fn pow(self: Self, exp: uint) - Self
}
Or, just use HasPow in your
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 ...
And of course it's possible to change something to a trait after the
fact without breaking API compatibility.
How you are doing this? I'm in fact a newbie in Rust, and it's interesting
that this can be done. std::num::pow() is a good example, I think.
Suppose I already have a program which is
I disagree with that: I never accept compromises, this is
the way how to develop magnificient software
Because it's not. Unless you use magnificient only in academic context.
? I'm not doing academic things.
It's not so much about wether or not overloading could be used in rust
without
Hello Rust folk!
I am new to Rust, and I have doubts concerning current language concepts.
One example: in module ::std::num function pow() is defined:
pub fn powT: One + MulT, T(mut base: T, mut exp: uint) - T {
if exp == 1 { base }
else {
let mut acc = one::T();
while
