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

Carter Schonwald carter.schonwald at gmail.com
Sat Jan 11 14:50:30 PST 2014


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 wrapping into negative numbers isn't a welcome suprise!


On Sat, Jan 11, 2014 at 5:38 PM, Owen Shepherd <owen.shepherd at e43.eu> wrote:

> On 11 January 2014 22:22, Daniel Micay <danielmicay at gmail.com> wrote:
>
>> On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd <owen.shepherd at e43.eu>
>> 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 mentioned: What I'd propose is trapping by default, with
>> non-trapping math along the lines of a single additonal character on a type
>> declaration away.
>>
>> Why would it be a language feature? It's not an operation Rust needs
>> to expose at a language level because it can be implemented as a
>> library type.
>>
>
> 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. "It'll never be a security issue", or "Looks safe to
> me", etc, etc. Secure by default is a good thing, IMO.
>
> So I agree, no reason it couldn't be implemented in libstd. Just... there
> are currently type names in the way.
>
> (I note that there has been a mixed opinion in this thread each way)
>
> Owen Shepherd
> http://owenshepherd.net | owen.shepherd at e43.eu
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140111/8205e45d/attachment.html>


More information about the Rust-dev mailing list