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 >> case like this in IRC recently involving mutable windows), then you have >> to abandon the for loop which is a big syntactic change (right now it >> works because it is ad-hoc). > > As of last week it's not anymore. > >> Similarly, when the operator overloading >> traits are insufficient, then you have to abandon that sugar as well. >> One might say "well, don't use those traits then" but that's not what >> happens in practice. In practice, people want the syntax sugar and >> therefore are guided into inefficiency. Some of BigNum's operator >> overloads shouldn't exist because they are so inefficient, and yet they >> do because people expect BigNum to act (on a syntactic level) just like >> any other number. >> >> So I think this is a real problem with real solutions that don't require >> going down the ad-hoc template black hole. > > 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 functions that want addable things. > > Patrick
We can start out with efficient generic code for bignums (meaning stuff like `op(&mut tmp, &a, &b)` in a loop with a reused temporary variable) and then add a "static" branch + other code for primitives as vector iterators already do for zero-size types. Ideally there would be a way of expressing it without relying on optimizations to remove a branch but the language is expressive enough other than that.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev