> 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
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? On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq < matthieu.monr...@gmail.com> wrote: > 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. > > 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 ? > > 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. > > This way we can have our cake and eat it too... or am I missing something ? > > -- Matthieu > > > > On Sun, Jun 22, 2014 at 5:45 AM, comex <com...@gmail.com> wrote: > >> On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay <danielmi...@gmail.com> >> wrote: >> >> Er... since when? Many single-byte opcodes in x86-64 corresponding to >> >> deprecated x86 instructions are currently undefined. >> > >> > http://ref.x86asm.net/coder64.html >> > >> > I don't see enough gaps here for the necessary instructions. >> >> You can see a significant number of invalid one-byte entries, 06, 07, >> 0e, 1e, 1f, etc. The simplest addition would just be to resurrect >> INTO and make it efficient - assuming signed 64 and 32 bit integers >> are good enough for most use cases. Alternatively, it could be two >> one-byte instructions to add an unsigned version (perhaps a waste of >> precious slots) or a two-byte instruction which could perhaps allow >> trapping on any condition. Am I missing something? >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
