Gregor,
I think the simple answer is that if your function needs to be broadly
extensible in the future and to have specialization, it needs to be
designed in the trait fashion, per the remarks earlier.
On Thu, Jul 24, 2014 at 5:46 PM, Gregor Cramer rema...@gmx.net wrote:
Hello Rust folk!
On 7/26/14 5:54 AM, SiegeLordEx wrote:
While this doesn't matter for the pow function (the alternate function
would just have a different path/name), it matters for the special
syntaxes. When the Iterator is no longer enough for you (there was a
case like this in IRC recently involving mutable
On 07/26/2014 12:56 PM, Patrick Walton wrote:
Well, part of the problem here is that people are going to want to write
generic functions that take addable values. If we start making `+` and
friends overloadable/ad-hoc, then people are going to be surprised when
they can't pass (say) bignums to
On 26/07/14 12:56 PM, Patrick Walton wrote:
On 7/26/14 5:54 AM, SiegeLordEx wrote:
While this doesn't matter for the pow function (the alternate function
would just have a different path/name), it matters for the special
syntaxes. When the Iterator is no longer enough for you (there was a
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
On 07/24/2014 06:46 PM, Gregor Cramer wrote:
1. Overloading is not supported (even the archaic C++ is providing this).
I should note that Rust provides a limited form of overloading via the
trait-double dispatch trick:
trait PowImplRes
{
fn pow(self, exp: uint) - Res;
}
fn powRes,
] std::num::pow() is inadequate / language concepts
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
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
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
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 powT: One + MulT, T(mut base: T, mut exp: uint) - T; //
uses the exponential trick
pub fn powi64(mut base: i64, mut exp: uint) - i64;
On 7/25/14 6:26 AM, Gregor Cramer wrote:
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
On 7/25/14 4:43 AM, SiegeLordEx wrote:
Yes, I concur on most of these points and I've brought up some related
points before. The operator overloading technique used by Rust is
antithetical to efficient generic code. The core numeric traits and
functions are currently designed only with built-in
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing that would work is
something like C++
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 code.
Why
On 7/25/14 10:11 AM, Oscar Boykin wrote:
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) -
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that calls
`pow` and works optimally with both bigints and
ints. I think the only thing
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 ...
On Fri, Jul 25, 2014 at 3:36 PM, Gregor Cramer rema...@gmx.net wrote:
I don't care about the capabilities of other languages, I don't use a
language if it is not appropriate.
Appropriate for what? You seem to be claiming that stable code in
general needs this feature, so that's consigning all
How can you disagree about what I'm doing?
I don't. 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 don't care about the capabilities of other languages, I don't
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
On Fri, Jul 25, 2014 at 1:45 PM, Gregor Cramer rema...@gmx.net wrote:
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 using std::num::pow() with a
self
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
On Fri, Jul 25, 2014 at 10:34 AM, Patrick Walton pcwal...@mozilla.com
wrote:
On 7/25/14 10:10 AM, Josh Haberman wrote:
On Fri, Jul 25, 2014 at 10:04 AM, Patrick Walton pcwal...@mozilla.com
wrote:
Neither auto-ref or ad-hoc operator overloading
would let you write a generic function that
On 7/25/14 3:20 PM, Josh Haberman wrote:
Got it. So the ad hoc part refers to having a template parameter, but
not being able to check its capabilities/interface at template
parsing/typechecking time, it sounds like?
Right. (The term comes from Making Ad-Hoc Polymorphism Less Ad-Hoc,
which is
On 25/07/14 08:46, Gregor Cramer wrote:
Probably in this case it might be a solution to move pow() into a
trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and
someone
is developing a new module for version 1.1. But some of the functions
in 1.0
are inadequate
On 07/24/2014 05:55 PM, Huon Wilson wrote:
1.0 will not stabilise every function in every library; we have precise
stability attributes[1] so that the compiler can warn or error if you
are using functionality that is subject to change. The goal is to have
the entirety of the standard library
On 7/24/14 3:46 PM, Gregor Cramer wrote:
Probably in this case it might be a solution to move pow() into a trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and someone
is developing a new module for version 1.1. But some of the functions in 1.0
are inadequate for the
On 25/07/14 09:21, Tommy M. McGuire wrote:
On 07/24/2014 05:55 PM, Huon Wilson wrote:
1.0 will not stabilise every function in every library; we have precise
stability attributes[1] so that the compiler can warn or error if you
are using functionality that is subject to change. The goal is to
29 matches
Mail list logo
