<div dir="ltr"><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>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 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 class="HOEnZb"><font color="#888888"><br><br>-- Matthieu<br><div><div><br></div></div></font></span></div><div class="HOEnZb"><div class="h5">

<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">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>