Rust's Two Kinds of 'Assert' Make for Better Code
1–10 of 87 posts
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#2> The problem that I’ve just expressed ultimately occurs because languages like C force us to encode both kinds of assumption with a single assert statement: either all asserts are compiled in or none are.
It’s trivial to write a debug_assert macro in C, so no, you’re not forced to do that.
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#3> The problem that I’ve just expressed ultimately occurs because languages like C force us to encode both kinds of assumption with a single assert statement: either all asserts are compiled in or none are. It’s trivial to write a debug_assert macro in C, so no, you’re not forced to do that.
It says so in the last paragraph
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#4I remember someone arguing that disabling assertions in prod is like wearing a life jacket in the harbor but throwing it overboard going to sea. And Moore's Law paid for them years ago.
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#5Swift calls these precondition() and assert(). Preconditions are enabled in release (and debug) builds, and asserts are enabled in debug builds only.
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#6Asserts are convenient, but every time I encounter them I ask "Can the compiler prove this can't happen?"
In the example of "min(ages) > 0", making age a NonZero type renders the assert unnecessary. Rust even has some fancy perf optimizations it can do with that information. It's a win all around.
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#7Is it common to use parenthesis for python assert statements?
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#8Asserts are convenient, but every time I encounter them I ask "Can the compiler prove this can't happen?" In the example of "min(ages) > 0", making age a NonZero type renders the assert unnecessary. Rust even has some fancy perf optimizations it can do with that information. It's a win all around.
If you created a custom NonZero type, how would the Rust compiler figure out how to optimize that?
How would one communicate properties/traits of a custom type (like a non-zero unit) that a compiler can leverage to optimize (in general, for any programming language)?
Re: Rust's Two Kinds of 'Assert' Make for Better Code
#9Common Lisp does assertions right: you can let `assert' provide a restart which allows the user to fix a problem when it crops up. For example:
(assert (Re: Rust's Two Kinds of 'Assert' Make for Better Code
#10Asserts are convenient, but every time I encounter them I ask "Can the compiler prove this can't happen?" In the example of "min(ages) > 0", making age a NonZero type renders the assert unnecessary. Rust even has some fancy perf optimizations it can do with that information. It's a win all around.
If you created a custom NonZero type, how would the Rust compiler figure out how to optimize that? How would one communicate properties/traits of a custom type (like a non-zero unit) that a compiler can leverage to optimize ( in general, for any programming language )?
I don't think the mechanics of being able to convey a niche are stable/developer-accessible, but NonZero is a type provided by the standard library: https://doc.rust-lang.org/std/num/struct.NonZero.html
An example of the niche optimisations is in that link; if a 32bit number is NonZero, you can put that in an Option, and your Option> will be the same size as a normal u32.