Hi,
I was reading https://github.com/mozilla/rust/wiki/Bikeshed-tailcall and
wondered about the statement Tail calls cannot be implemented in general
without a serious performance hit for all calls. I've never heard this
before. tjc speculated it had to do with decrementing refcounts on normal
On 1/25/12 10:42 AM, Matthew O'Connor wrote:
Hi,
I was reading https://github.com/mozilla/rust/wiki/Bikeshed-tailcall and
wondered about the statement Tail calls cannot be implemented in
general without a serious performance hit for all calls. I've never
heard this before. tjc speculated it had
Currently it is simply '+'.
The thing that prompted this is issue #1520 -- operator overloading.
Delegating + on non-builtin-numeric types to a `num` interface that
implements methods add/sub/mult/div/rem/neg methods seems elegant, and
similar to Haskell's approach. Vector-concatenation + messes
On 1/25/12 11:46 AM, Marijn Haverbeke wrote:
Currently it is simply '+'.
The thing that prompted this is issue #1520 -- operator overloading.
Delegating + on non-builtin-numeric types to a `num` interface that
implements methods add/sub/mult/div/rem/neg methods seems elegant, and
similar to
What about an add interface?
That works, but doesn't provide the conceptual simplicity of a number
interface, and if you want to write a generic over any numeric type,
it could end up taking a T: add, mult, sub, div type parameter.
___
Rust-dev mailing
(1) Typeclass imports become import impl. So you'd write import impl
driver::diagnostic::handler where you'd write import
driver::diagnostic::handler today. This way, when you look at a method call
and you don't know where it's coming from, you just grep for import impl
and look at all the
There are cases in math or physics when the granularity is needed. For example,
when implementing vectors (in the math or physics sense), it doesn't make sense
to define a division operator, and what you mean by multiplication depends on
if you mean dot product, cross product, or whatever. It'd
On 24/01/2012 12:24 PM, Thomas Leonard wrote:
Basically, I'd like to make a list of short-comings in existing
installation systems that cargo addresses (e.g. poor documentation,
too many dependencies, lack of robustness, poor security, etc).
Summary version: too many concepts and moving
On 1/25/12 12:18 PM, Marijn Haverbeke wrote:
That works, but doesn't provide the conceptual simplicity of a number
interface, and if you want to write a generic over any numeric type,
it could end up taking aT: add, mult, sub, div type parameter.
It seems to me that if impls did not have to
