<div dir="ltr"><div><div><div><div><div>> There are plenty of other features to Rust then "absolute speed".<br><br></div>You're right. Here are the three primary features of Rust, in decreasing order of importance:<br>

<br></div>    1. Memory safety<br></div>    2. C++ performance<br></div>    3. Safe concurrency<br><br></div>Notably, correctness in the face of integer overflow is merely a nice-to-have, and if it would compromise the second principle then we cannot accept it. The only features that are allowed to compromise performance are those that are required to satisfy memory safety, and the developers have already concluded that defined integer overflow does not jeopardize memory safety. Your only recourse is to convince the developers that they are incorrect and that overflow semantics are in fact a memory safety hazard. Railing against the incorrectness of overflow semantics alone isn't going to sway anyone.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 11:39 AM, Evan G <span dir="ltr"><<a href="mailto:eg1290@gmail.com" target="_blank">eg1290@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>Because of memory safety? Because you want low-level control without absolute speed? Because of a small memory footprint? Because of having a good async story without giving up a lot of speed? <br><br>

</div>

There are plenty of other features to Rust then "absolute speed". Just because that's <i>your</i> usecase for it doesn't mean you should force it on others.<br></div><div class="HOEnZb"><div class="h5">

<div class="gmail_extra"><br><br><div class="gmail_quote">

On Sun, Jun 22, 2014 at 10:32 AM, Benjamin Striegel <span dir="ltr"><<a href="mailto:ben.striegel@gmail.com" target="_blank">ben.striegel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="ltr"><div><div>> Even though Rust is a performance conscious language (since it aims at 
displacing C and C++), the 80/20 rule still applies and most of Rust 
code should not require absolute speed<br><br></div></div>This is a mistaken assumption. Systems programming exists on the extreme end of the programming spectrum where edge cases are the norm, not the exception, and where 80/20 does not apply. If you don't require absolute speed, why are you using Rust?<br>





</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq <span dir="ltr"><<a href="mailto:matthieu.monrocq@gmail.com" target="_blank">matthieu.monrocq@gmail.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I am not a fan of having wrap-around and non-wrap-around types, because whether you use wrap-around arithmetic or not is, in the end, an implementation detail, and having to switch types left and right whenever going from one mode to the other is going to be a lot of boilerplate.<br>






<br></div>Instead, why not take the same road than swift and map +, -, * and / to non-wrap-around operators and declare new (more verbose) operators for the rare case where performance matters or wrap-around is the right semantics ?<br>






<br></div>Even though Rust is a performance conscious language (since it aims at displacing C and C++), the 80/20 rule still applies and most of Rust code should not require absolute speed; so let's make it convenient to write safe code and prevent newcomers from shooting themselves in the foot by providing safety by default, and for those who profiled their applications or are writing hashing algorithms *also* provide the necessary escape hatches.<br>






<br></div>This way we can have our cake and eat it too... or am I missing something ?<span><font color="#888888"><br><br>-- Matthieu<br><div><div><br></div></div></font></span></div><div><div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 5:45 AM, comex <span dir="ltr"><<a href="mailto:comexk@gmail.com" target="_blank">comexk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay <<a href="mailto:danielmicay@gmail.com" target="_blank">danielmicay@gmail.com</a>> wrote:<br>







>> Er... since when?  Many single-byte opcodes in x86-64 corresponding to<br>
>> deprecated x86 instructions are currently undefined.<br>
><br>
> <a href="http://ref.x86asm.net/coder64.html" target="_blank">http://ref.x86asm.net/coder64.html</a><br>
><br>
> I don't see enough gaps here for the necessary instructions.<br>
<br>
</div>You can see a significant number of invalid one-byte entries, 06, 07,<br>
0e, 1e, 1f, etc.  The simplest addition would just be to resurrect<br>
INTO and make it efficient - assuming signed 64 and 32 bit integers<br>
are good enough for most use cases.  Alternatively, it could be two<br>
one-byte instructions to add an unsigned version (perhaps a waste of<br>
precious slots) or a two-byte instruction which could perhaps allow<br>
trapping on any condition.  Am I missing something?<br>
<div><div>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>