[rust-dev] Integer overflow, round -2147483648

Benjamin Striegel ben.striegel at gmail.com
Mon Jun 23 14:38:26 PDT 2014

> I feel like Rust might be missing out on the free lunch I expect Swift to

I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest benefactor
of LLVM, which powers the C compiler their OS is built with, the
Objective-C language that all their apps are written in, the IDE used to
write those apps, and the Javascript engine that powers their web browser.
Despite Swift's arrival, I wouldn't expect any greater investment in LLVM
than Apple does currently (which is a shame, given the bazillion dollars
burning a hole in their pocket).

I'd like to also note that Apple has no external incentive to improve
Swift. Objective-C was a dead language before Apple's fiat rocketed it into
the position of world's third-most-popular programming language. Regardless
of Swift's implementation or design decisions, it *will* be one of the most
popular languages in the world come this time next year (likely accompanied
by Objective-C's meteoric descent). If Swift were a fusion of RPG and
Malbolge with an implementation written in INTERCAL, this fact would not
change (thankfully, the Swift designers have better taste). Why bother
straining yourself to satisfy a captive audience, when your only real
competitor is whatever dialect of Java that Dalvik supports?

On Mon, Jun 23, 2014 at 5:08 PM, Tony Arcieri <bascule at gmail.com> wrote:

> On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay <danielmicay at gmail.com>
> wrote:
>> It would be an enormous mistake to ship a language with region typing /
>>  move semantics and worse before than Java.
> You keep saying that, but if the argument is to use Swift's approach, i.e.:
> Non-overflow operators: + - * / %
>  Overflow operators: &+ &- &* &/ &%
> Or let's swap Swift's defaults if you so desire:
> Overflow operators: + - * / %
> Non-overflow operators: &+ &- &* &/ &%
> Or even change the syntax if you so desire:
> Overflow operators: + - * / %
> Non-Overflow operators: +~ -~ *~ /~ %~
> ...then any arguments about performance are really a false dichotomy. It's
> just a question of syntax and defaults. Want to perform well at TIOBE or
> other (micro)benchmarks? Use the overflow operators! Want to write safe
> code? Use the checked overflow operators. I really think Rust should
> support both approaches, be it implemented through a type or operator or
> what have you. I'm not here to bikeshed that. I just want to make sure both
> approaches have a first class position in the language, and would generally
> prefer but don't insist upon checked overflow being the default.
> If the Rust developers insist on choosing overflow operators as the One
> True Way To Do Math, well, that's your prerogative. I will probably still
> choose Rust over Swift. But then I feel like Rust might be missing out on
> the free lunch I expect Swift to provide, which is sad if that's the way
> the cookie crumbles...
> --
> Tony Arcieri
> _______________________________________________
> 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/20140623/20cbba88/attachment.html>

More information about the Rust-dev mailing list