21–30 of 227 posts
> array[i] will check to make sure that array has at least i elements. At least i+1 elements, right? Or am I getting caught up by one of the three hardest problems again?
Edit: brain not woken up yet. It’s because of zero indexing. ———- Original question: Out of curiosity, why the +1?
> array[i] will check to make sure that array has at least i elements. At least i+1 elements, right? Or am I getting caught up by one of the three hardest problems again?
Edit: brain not woken up yet. It’s because of zero indexing. ———- Original question: Out of curiosity, why the +1?
This rather niche fixing of unsafe behaviour is excellent: https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html#fixin... I spent a few years as a scientific programmer and this is exactly the sort of thing that just bites you on the behind in C/C++/Fortran: the undefined behaviour can actually manifest as noise in your output, or just really hard to track down, intermittent problems. A big win to get rid of it.
I'm not sure I understand this. Does it not produce a run time error? Why not? This looks very dangerous, because it essentially does the "nearest to right" thing. Say, you cast 256 to a u8, it's then saturated to 255. That's almost right, and a result might be wrong only by 0.5%. Much harder to detect than if it is set to 0.
It’s not supposed to. Type casting with ‘as’ is supposed to be lightweight and always succeed; there is no room in the type system to return an error. In case lossless casting is not possible, some value still has to be returned. Until now, this was outright UB — meaning the compiler is not even obligated to keep it consistent from one build to another. Saturating, while still not optimal, is at least deterministic.
> This looks very dangerous, because it essentially does the "nearest to right" thing.
That’s why the intention is to introduce more robust approximate conversion functions and eventually probably deprecate ‘as’ casts altogether. There has been a number of discussions about this; current disagreements seem to be about how to handle the various possible rounding modes.
Earlier quoted context omitted.
Edit: brain not woken up yet. It’s because of zero indexing. ———- Original question: Out of curiosity, why the +1?
Arrays start at 0. example_array[5] is actually the 6th number in the array.
By any chance if anyone is in the Paris area and is interested to teach Rust at university next year during the first semester. Please get in touch :).
What university ? Would love to take the resulting course
Earlier quoted context omitted.
Edit: brain not woken up yet. It’s because of zero indexing. ———- Original question: Out of curiosity, why the +1?
Zero indexing probably
This rather niche fixing of unsafe behaviour is excellent: https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html#fixin... I spent a few years as a scientific programmer and this is exactly the sort of thing that just bites you on the behind in C/C++/Fortran: the undefined behaviour can actually manifest as noise in your output, or just really hard to track down, intermittent problems. A big win to get rid of it.
well done rust team
Rust 1.45 will be the Rocket Release. It unblocks Rocket running on stable as tracked here https://github.com/SergioBenitez/Rocket/issues/19
This is so excellent, and I love seeing long term, multiyear goals get completed. It isn't just this release, but all the releases in between. The Rust team and community is amazing.
https://github.com/SergioBenitez/Rocket on stable rust finally!
At the moment, I'd rather use something like actix-web instead.