[rust-dev] resolving 'str'

2014-07-26 Thread Phil Dawes
Hello! I'm trying to make racer resolve 'str' types properly. I've read that the separation of type and value namespaces means you can refer both to the 'str' type and the 'str' module[1]. However I would have thought that the 'str' type lives in the type namespace, and according to the reference

Re: [rust-dev] std::num::pow() is inadequate / language concepts

2014-07-26 Thread Patrick Walton
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

Re: [rust-dev] std::num::pow() is inadequate / language concepts

2014-07-26 Thread SiegeLordEx
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

Re: [rust-dev] std::num::pow() is inadequate / language concepts

2014-07-26 Thread Daniel Micay
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

[rust-dev] std::num::pow() is inadequate / language concepts

2014-07-26 Thread Ariel Ben-Yehuda
std::num::pow is not the most general exponentiation function but a second-rate utility function in the standard library - you don't have to use it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] std::num::pow() is inadequate / language concepts

2014-07-26 Thread Ariel Ben-Yehuda
[The previous message got sent accidentally by gmail] However, for performance reasons, I think some kind of trait overloading would be nice. i.e., you should be able to do implT TraitT for Aφ { ... } overload impl Traitint for Aφ[int/T] { //... } And when using (x : Traitint) the