251–260 of 283 posts
Earlier quoted context omitted.
I wonder how many processors there are in use these days that don't use 2s complement. I don't think I've ever seen one.
The bigger reason it's still undefined is to enable this type of optimization: https://news.ycombinator.com/item?id=14857316
Earlier quoted context omitted.
Unless you are paid by the line that should either work as "expected" (i.e. wrap) or produce an error about a meaningless comparison. Is it worth a few developer days worth of work to track down a hard to repro bug that only happens with hard to debug optimizations enabled?
No, which is one reason why I almost always use unsigned types in my C code, particularly in the context of data structure management where negative values are unnecessary and usually non-sensical. GCC supports -fwrapv and -fno-strict-overflow; and I think clang supports both, too. I've never cared to use them because I only rarely use signed types. But some projects and programmers use those options habitually. AFAI…
Overflow of any integer type is considered a "program error", not undefined behavior. In debug builds, this is required to panic. In builds where it doesn't panic, it's well-defined as two's compliment wrapping.
You can also request explicit wrapping, saturating, etc behavior.
The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. It would be easier if Rust had real multidimensional arrays. If the compiler knows about multidimensional arrays, some additional optimizations are possible. For example, if you want to b…
.split_at_mut is a method on a slice ... one is free to implement their own abstractions that ultimately terminate in an unsafe { block } that enable multiple mutable borrows. fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str) { // is_char_boundary checks that the index is in [0, .len()] if self.is_char_boundary(mid) { let len = self.len(); let ptr = self.as_ptr() as *mut u8; unsafe { (from_raw_parts_mut(…
Earlier quoted context omitted.
What if your target architecture has a different vector width and hence you're using 4 element vectors but wasting 12? If you want to use vectors explicitly, you can do so using intrinsics for most vector architectures.
The sizes I mentioned are extremely common in 2d and 3d geometry. This is due to the number of dimensions visible in our world. While someone may want to run 11 dimensional calculations in string theory, there are a large number of common real-world applications of the lengths 2,3,4. In C and C++ you can often use intrinsics but the big 3 - ARM, Intel, PPC - all define them differently. I want this common stuff to be…
Assuming that's true, you want to maximise performance by using as much of the parallelism that vectors give you. So if you're dealing with [4 x int32], on a 128 bit vector ISA you would be fully utilising your vector registers, but moving to say AVX-512 you're now only using 1/4 of your potential parallelism.
Your architecture independent vector types would have to target the lowest common denominator, and completely defeat the purpose of vectorisation.
Earlier quoted context omitted.
Seems like (from that Reddit thread) a lot of the things are in progress in the nightlies. I wonder if that means the nightlies are holding Rust back (because it relieves the pressure to actually ship features for use by normal developers).
Trust me, being available only on nightly does not reduce pressure :) Most of our users use stable, and want to stick to stable. There's just some use-cases that need features we haven't finished designing yet, such is life.
Contrast this with other languages (C++, Python, Ruby, Go) where I have no idea what features are under development until they hit a stable release. Compare to JavaScript, where stable releases are so slow people built transpilers ;)
This could also be because I'm interested enough in Rust to occasionally land on the first-party discussion forums, of course (probably helped by how open the language development is). I'd say it's also young, except that it now has a release number much larger than 1.0 and doesn't really get to claim that anymore.
Earlier quoted context omitted.
Yes, that's right, and multiple compilers support the Windows C++ ABI. You still couldn't write portable C++ in C or assembly (or anything else not C++). Does anyone write C or assembly to that ABI? Probably not, though to be fair that's probably in large part because if you're going to do that you might as well write in C++ :^) Still, I think a public and stable ABI with fine-grained control of binary elements is a…
As a counterpoint, PowerPC has at least 3 mutually incompatible ABIs for C.
Earlier quoted context omitted.
.split_at_mut is a method on a slice ... one is free to implement their own abstractions that ultimately terminate in an unsafe { block } that enable multiple mutable borrows. fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str) { // is_char_boundary checks that the index is in [0, .len()] if self.is_char_boundary(mid) { let len = self.len(); let ptr = self.as_ptr() as *mut u8; unsafe { (from_raw_parts_mut(…
What does Rust have Ocaml doesn't? If Ocaml solves the problem why Rust? Rust was made to solve the problem Ada solves.
Safe memory management without a garbage collector.
> If Ocaml solves the problem why Rust?
Ocaml doesn't solve every problem any more than Rust does. Rust may solve a subset of the problems people use the listed languages for better than those languages, so it might be beneficial for people to use it in those cases.
> Rust was made to solve the problem Ada solves.
Not all solutions have the same efficiency, or are as easy to understand. Rust aims to enforce safety at compile time to eliminate runtime safety checks where possible. Ada performs many safety checks at runtime, which introduces a performance cost. This does allow Ada to provide some additional safety checks though (such as limiting a type/subtype to a range of values).
Earlier quoted context omitted.
Trust me, being available only on nightly does not reduce pressure :) Most of our users use stable, and want to stick to stable. There's just some use-cases that need features we haven't finished designing yet, such is life.
Might very well be; I have the luxury of not looking a nightlies at all :) it's just been frustrating how often problem reports get a response that the solutions are in the nightlies. I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining", but the acknowledgement that it's actually an issue for people using release builds seem to be missing when…
I think that's the right assumption, because it's an acknowledgement that the issue actively being worked on to the degree that they have at least a partial solution implemented, as opposed to the "someone is working on that" response language developers sometimes give which usually predates that and could mean someone is reading literature and surveying the field and no code has actually been written.
As you note, because development is so open, nightlies are easily accessible, so people might incorrectly infer that they are being recommended to use them, or that the problem is solved. I think what the devs are attempting to communicate is that it's close, and if you want you can test it out to see what it's like and give feedback. This might be a case of similar groups with slightly different context (lang devs / lang users) interpret a statement differently. From what I've seen, the Rust devs see fairly responsive to communication issues when pointed out, so maybe this will result in some change (or perhaps they are acutely aware of the issue already and instituted changes have not shown benefit, at least yet).
Earlier quoted context omitted.
The latest on this front: http://blog.japaric.io/rtfm-v2/
Found this paper useful: "The Case for Writing a Kernel in Rust" ( https://www.tockos.org/assets/papers/rust-kernel-apsys2017.p... ) linked from the "tock os" blog post: https://www.tockos.org/blog/2017/apsys-paper/