[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

This may be go nowhere, especially so late in Rust's development, but I feel like this is an important, relatively small change (though a high-profile one). I believe it could have a large, positive impact in terms of targeting new developer communities, gaining more libraries and applications

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

The current consensus on this subject, afaik, is the rename int/uint to intptr/uintptr. They're awful names, but it frees up int for a *fast* bigint type. Fast here is key. We can't have a suboptimal numeric type be the recommended default. We need to perform at least as well as GMP for me to even

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 1/10/14 9:41 PM, Corey Richardson wrote: The current consensus on this subject, afaik, is the rename int/uint to intptr/uintptr. They're awful names, but it frees up int for a *fast* bigint type. Fast here is key. We can't have a suboptimal numeric type be the recommended default. We need to p

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Friday, January 10, 2014, Lee Braiden wrote: > This may be go nowhere, especially so late in Rust's development, but I > feel like this is an important, relatively small change (though a > high-profile one). I believe it could have a large, positive impact in > terms of targeting new develope

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 11/01/14 16:48, Patrick Walton wrote: On 1/10/14 9:41 PM, Corey Richardson wrote: The current consensus on this subject, afaik, is the rename int/uint to intptr/uintptr. They're awful names, but it frees up int for a *fast* bigint type. Fast here is key. We can't have a suboptimal numeric typ

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Scheme's numeric tower is one of the best in extant languages. Take a look at it. Of course, its dynamic typing is poorly suited for Rust. Arbitrary-precision arithmetic can get you mathematically perfect integers and rational numbers, but not real numbers. There are an uncountably infinite

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden wrote: > This may be go nowhere, especially so late in Rust's development, but I feel > like this is an important, relatively small change (though a high-profile > one). I believe it could have a large, positive impact in terms of > targeting new deve

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 11/01/14 16:58, Isaac Dupree wrote: Scheme's numeric tower is one of the best in extant languages. Take a look at it. Of course, its dynamic typing is poorly suited for Rust. Arbitrary-precision arithmetic can get you mathematically perfect integers and rational numbers, but not real numb

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 12:48 AM, Patrick Walton wrote: > On 1/10/14 9:41 PM, Corey Richardson wrote: >> >> The current consensus on this subject, afaik, is the rename int/uint >> to intptr/uintptr. They're awful names, but it frees up int for a >> *fast* bigint type. Fast here is key. We can't ha

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: > On 11/01/14 16:58, Isaac Dupree wrote: >> >> Scheme's numeric tower is one of the best in extant languages. Take a >> look at it. Of course, its dynamic typing is poorly suited for Rust. >> >> Arbitrary-precision arithmetic can get you mathem

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 01/10/2014 10:08 PM, Daniel Micay wrote: On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: On 11/01/14 16:58, Isaac Dupree wrote: Scheme's numeric tower is one of the best in extant languages. Take a look at it. Of course, its dynamic typing is poorly suited for Rust. Arbitrary-precisi

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: >>> >>> On 11/01/14 16:58, Isaac Dupree wrote: Scheme's numeric tower is one of the best in extant languages. Take a look

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 1/10/14 10:05 PM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 12:48 AM, Patrick Walton wrote: >> On 1/10/14 9:41 PM, Corey Richardson wrote: >>> >>> The current consensus on this subject, afaik, is the rename int/uint >>> to intptr/uintptr. They're awful names, but it frees up int for a >>> *

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson wrote: > > We need to perform at least as well as GMP for me to even consider it. The only realistic way to accomplish this is using GMP. Lots of other big integer implementations exist with lots of work put into them and the performance is not e

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

C and C++ have a `stdint.h` header defining fixed-size integers. Rust doesn't have any arbitrarily defined integer types like C. It has 8/16/32/64-bit variants of both signed and unsigned integers, along with pointer-size integers covering the address space (int and uint).

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Simple answer: then it shouldn't be our default numeric type. You say earlier that we don't need a default, and that is a case I hadn't considered before. But I'm growing to like it. On Sat, Jan 11, 2014 at 1:23 AM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson wrote:

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

> The branch on the overflow flag results in a very significant loss in > performance. For example, I had to carefully write the vector `push` > method for my `Vec` type to only perform one overflow check. With > two checks, it's over 5 times slower due to failed branch predictions. > Huh, that's

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

corey, those would be very very nice refinments and a healthy progressive yet conservative stance that leaves the room for evolving healthy defaults (I've a slow boil program to bring breaking changes to fix numerical warts in haskell over the next 2-3 years, ) @corey, one example of a "Real" numb

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald wrote: > corey, those would be very very nice refinments and a healthy progressive > yet conservative stance that leaves the room for evolving healthy defaults > (I've a slow boil program to bring breaking changes to fix numerical warts > in haskel

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

sounds like we agree! (and thanks for clarifying some of the detail points i neglected) On Sat, Jan 11, 2014 at 2:27 AM, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald > wrote: > > corey, those would be very very nice refinments and a healthy progressive > > yet conse

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

I am not aware of an efficient way to provide automatic-overflow-to-bignum semantics in a non-garbage-collected language, without also imposing the burden of references/move semantics/etc on users of small integers. I.e. integers, if they may hold references to allocated memory can no longer sanely

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

There is static analysis (i.e. determine ahead of time exactly what values variables may take), but it's certainly not a panacea: the analysis step is slow (probably too slow to fully integrate into a compiler), not everything can be solved, and most existing solvers are not free software as far

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 11 January 2014 06:20, Daniel Micay wrote: > The branch on the overflow flag results in a very significant loss in > performance. For example, I had to carefully write the vector `push` > method for my `Vec` type to only perform one overflow check. With > two checks, it's over 5 times slower d

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 11:54 AM, Owen Shepherd wrote: > On 11 January 2014 06:20, Daniel Micay wrote: >> >> The branch on the overflow flag results in a very significant loss in >> performance. For example, I had to carefully write the vector `push` >> method for my `Vec` type to only perform on

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson wrote: >>> >>> On 11/01/14 16:58, Isaac Dupree wrote: Scheme's numeric tower is one of the best in extant languages. Take a look

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

> > Hitting a slow path unexpectedly on overflow seems to me like a recipe > for > > unpredictable performance, which doesn't seem inline with Rust's usual > > goals. > > It's certainly better than the process exiting, which is what's going > to happen in real systems when failure occurs. Either th

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

So I just did a test. Took the following rust code: pub fn test_wrap(x : u32, y : u32) -> u32 { return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); } And got the following blob of assembly out. What we have there, my friends, is a complete failure of the optimizer (N.B. it works for t

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd wrote: > So I just did a test. Took the following rust code: > pub fn test_wrap(x : u32, y : u32) -> u32 { > return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); > } > > And got the following blob of assembly out. What we have there, my fr

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 11 January 2014 21:42, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd > wrote: > > So I just did a test. Took the following rust code: > > pub fn test_wrap(x : u32, y : u32) -> u32 { > > return x.checked_mul(&y).unwrap().checked_add(&16).unwrap(); > > } > > > > And g

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd wrote: > > What about other workloads? It just depends on how much of it is doing integer arithmetic. Many applications are bounded by I/O and memory bandwidth and wouldn't be hurt by integer arithmetic resulting in significantly slower code. > As I

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 11 January 2014 22:22, Daniel Micay wrote: > On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd > wrote: > > > > What about other workloads? > > It just depends on how much of it is doing integer arithmetic. Many > applications are bounded by I/O and memory bandwidth and wouldn't be > hurt by in

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

excellent point owen. I'd agree myself, seeing how that exact same platform dependent int/uint size gotchas (wrapping style semantics) are a recurrent source of surprise in GHC Haskell, and other languages. In my own applications I like wrapping semantics, but for most people, a signed counter wrap

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 01/10/2014 10:08 PM, Daniel Micay wrote: I don't think failure on overflow is very useful. It's still a bug if you overflow when you don't intend it. If we did have a fast big integer type, it would make sense to wrap it with an enum heading down a separate branch for small and large integers,

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

I think failure may have quite different inlining costs once we move to libunwind-based backtraces instead of hardcoding file/line number information into the generated code. The file and line number information tends to pollute generated code a lot and it's basically unnecessary with proper DWA

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 6:06 PM, Nathan Myers wrote: > On 01/10/2014 10:08 PM, Daniel Micay wrote: >> >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. If we did have a fast big >> integer type, it would make sense to wrap it with an

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 1/10/14 10:08 PM, Daniel Micay wrote: I don't think failure on overflow is very useful. It's still a bug if you overflow when you don't intend it. Of course it's useful. It prevents attackers from weaponizing out-of-bounds reads and writes in unsafe code. Patrick

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 01/11/2014 03:14 PM, Daniel Micay wrote: On Sat, Jan 11, 2014 at 6:06 PM, Nathan Myers wrote: A big-integer type that uses small-integer arithmetic until overflow is a clever trick, but it's purely an implementation trick. Architecturally, it makes no sense to expose the trick to users. I

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 11/01/2014 22:38, Owen Shepherd wrote: I agree, however, I feel that the names like "i32" and "u32" should be trap-on-overflow types. The non overflow ones should be "i32w" (wrapping) or similar. Why? Because I expect that otherwise people will default to the wrapping types. Less typing. "

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 13/01/14 00:23, james wrote: On 11/01/2014 22:38, Owen Shepherd wrote: I agree, however, I feel that the names like "i32" and "u32" should be trap-on-overflow types. The non overflow ones should be "i32w" (wrapping) or similar. Why? Because I expect that otherwise people will default to th

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 12 January 2014 13:23, james wrote: > On 11/01/2014 22:38, Owen Shepherd wrote: > >> I agree, however, I feel that the names like "i32" and "u32" should be >> trap-on-overflow types. The non overflow ones should be "i32w" (wrapping) >> or similar. >> >> Why? Because I expect that otherwise peo

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 13 Jan 2014, at 12:34 am, Owen Shepherd wrote: > But I also feel that by making the unchecked ones the shorter name, the > language would be implicitly sending a message that they're preferred. Custom operator time! Say hello to our checked operators: trait CheckedAdd { fn inf

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Isaac Dupree wrote: > In general, Rust is a systems language, so fixed-size integral types are > important to have. They are better-behaved than in C and C++ in that > signed types are modulo, not undefined behaviour, on overflow. It could > be nice to have integral types that are task-failur

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Another sweet spot for a few applications is larger-than-word-sized fixed-width types, such as a 128 or 192 bit (u)int. This is useful for code that has to deal with values larger than 64 bits but within, say, 256 or 512 bits (above this, I think the costs of dynamic allocation and non-inlined

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 12 January 2014 19:02, Isaac Dupree wrote: > Another sweet spot for a few applications is larger-than-word-sized > fixed-width types, such as a 128 or 192 bit (u)int. This is useful for > code that has to deal with values larger than 64 bits but within, say, 256 > or 512 bits (above this, I th

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sun, Jan 12, 2014 at 1:23 PM, Tobias Müller wrote: > Isaac Dupree > wrote: >> In general, Rust is a systems language, so fixed-size integral types are >> important to have. They are better-behaved than in C and C++ in that >> signed types are modulo, not undefined behaviour, on overflow. It

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sun, Jan 12, 2014 at 2:09 PM, Owen Shepherd wrote: > > For implementing bignum arithmetic, this is obviously a point where a > "natural int" type would be best (probably the biggest which fits a single > register) If you plan on writing a competitive big integer library, then the integer size

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke wrote: > I am not aware of an efficient way to provide > automatic-overflow-to-bignum semantics in a non-garbage-collected > language, without also imposing the burden of references/move > semantics/etc on users of small integers. I.e. integers, i

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sun, Jan 12, 2014 at 3:55 PM, Gábor Lehel wrote: > > > > On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke > wrote: >> >> I am not aware of an efficient way to provide >> automatic-overflow-to-bignum semantics in a non-garbage-collected >> language, without also imposing the burden of referen

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

I think in theory we could arrange for the signal handler to trigger unwinding or use Windows SEH, which is zero cost on 64 bit AIUI. Daniel Micay wrote: >On Sun, Jan 12, 2014 at 3:55 PM, Gábor Lehel >wrote: >> >> >> >> On Sat, Jan 11, 2014 at 11:18 AM, Marijn Haverbeke > >> wrote: >>> >>> I am

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sun, Jan 12, 2014 at 12:59 PM, Patrick Walton wrote: > On 1/10/14 10:08 PM, Daniel Micay wrote: > >> I don't think failure on overflow is very useful. It's still a bug if >> you overflow when you don't intend it. >> > > Of course it's useful. It prevents attackers from weaponizing > out-of-boun

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sat, Jan 11, 2014 at 5:49 PM, Nathan Myers wrote: > No one would complain about a built-in "i128" type. The thing > about a fixed-size type is that there are no implementation > choices to leak out. Overflowing an i128 variable is quite > difficult, and 128-bit operations are still lots faste

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Sun, Jan 12, 2014 at 8:01 PM, Robert O'Callahan wrote: > On Sun, Jan 12, 2014 at 12:59 PM, Patrick Walton > wrote: >> >> On 1/10/14 10:08 PM, Daniel Micay wrote: >>> >>> I don't think failure on overflow is very useful. It's still a bug if >>> you overflow when you don't intend it. >> >> >> Of

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 1/12/14 5:22 PM, Daniel Micay wrote: As far as I know, doing more takes way too long. Eliminating array bounds checks and reasoning about arithmetic just doesn't really happen. I think the jury is still out. See "A Fast and Low-Overhead Technique to Secure Programs Against Integer Overflows

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay wrote: > -fsanitize=signed-integer-overflow: Signed integer overflow, including > all the checks added by -ftrapv, and checking for overflow in signed > division (INT_MIN / -1). > > Why not measure the impact of this on Firefox performance? We'll have

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

@daniel, the GHC haskell IR predates LLVM, and theres actually some pretty nice examples of LLVM doing AMAZING optimization of bit fiddling haskell code (in fact, for any performance ratio, i can manufacture a natural bit fiddlign example where ghc -fllvm is that much better than ghc -fasm for bit

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Would it be accurate to say that the only significant changes required at the language level for all this would be not having a default integer type, and then probably polymorphic number literals a la Haskell? And that the rest of this discussion is only about policy and ergonomics? On Mon, Jan 1

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Daniel Micay wrote: > On Sun, Jan 12, 2014 at 1:23 PM, Tobias Müller wrote: >> Isaac Dupree >> wrote: >>> In general, Rust is a systems language, so fixed-size integral types are >>> important to have. They are better-behaved than in C and C++ in that >>> signed types are modulo, not undefined

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

enforce what statically? There is a very really very subtle tradeoff in how powerful a static verification scheme can be vs how easily it can be used (the sweet spot being somewhere in between nothing and complete proof based verification). It sounds like there are valid arguments for several d

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Carter Schonwald wrote: > enforce what statically? There is a very really very subtle tradeoff in > how powerful a static verification scheme can be vs how easily it can be > used (the sweet spot being somewhere in between nothing and complete > proof based verification). Enforce that integer

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

indeed, hence why i was saying there should be sized int variants for each of those semantics (wrapping, trapping, overflowing, etc). This is something that many people seem to favor, and is the right choice for supporting smart engineers build reliable sophisticated software. Namely, really spell

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Carter Schonwald wrote: > indeed, hence why i was saying there should be sized int variants for > each of those semantics (wrapping, trapping, overflowing, etc). This is > something that many people seem to favor, and is the right choice for > supporting smart engineers build reliable sophisticate

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller wrote: > Daniel Micay wrote: > > On Sun, Jan 12, 2014 at 1:23 PM, Tobias Müller > wrote: > >> Isaac Dupree > >> wrote: > >>> In general, Rust is a systems language, so fixed-size integral types > are > >>> important to have. They are better-beha

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller wrote: > int + int = int > ... > > If the result does not fit into an int the compiler throws an error. > To resolve an error, you can: > - annotate the operands with appropriate bounds > - use a bigger type for the operation and check the result. I

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Tue, Jan 14, 2014 at 5:56 AM, comex wrote: > On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller wrote: > > int + int = int > > ... > > > > If the result does not fit into an int the compiler throws an error. > > To resolve an error, you can: > > - annotate the operands with appropriate bounds > >

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On 14/01/14 01:50, Palmer Cox wrote: On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller > wrote: Daniel Micay mailto:danielmi...@gmail.com>> wrote: > Do you know what undefined behavior is? It doesn't mean unspecified. True, but despite beeing so often cite

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Lee Braiden wrote: > On 14/01/14 01:50, Palmer Cox wrote: > > On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller > > wrote: > > Daniel Micay > wrote: > > Do you know what undefined behavior is? It doesn't mean unspecified. > >

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

comex wrote: > On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller wrote: >> int + int = int >> ... >> >> If the result does not fit into an int the compiler throws an error. >> To resolve an error, you can: >> - annotate the operands with appropriate bounds >> - use a bigger type for the operation a

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Tue, Jan 14, 2014 at 3:16 PM, Tobias Müller wrote: > Lee Braiden wrote: >> On 14/01/14 01:50, Palmer Cox wrote: >> >> On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller >> > > wrote: >> >> Daniel Micay > > wrote: >> > Do you know what u

Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

On Fri, Jan 10, 2014 at 9:15 PM, Lee Braiden wrote: > > http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/ > Just wanted to mention that Swift's approach seems interesting here: by default check for overflow consider it an error if i