Skip to content

Commit

Permalink
Update to reflect what was decided
Browse files Browse the repository at this point in the history
  • Loading branch information
pcwalton committed May 2, 2014
1 parent 0580a69 commit c986337
Showing 1 changed file with 4 additions and 6 deletions.
10 changes: 4 additions & 6 deletions active/0000-assert.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,23 +4,21 @@

# Summary

Asserts are too expensive for release builds and mess up inlining. There must be a way to turn them off. I propose macros `assert!` and `enforce!`. For test cases, `enforce!` should be used.
Asserts are too expensive for release builds and mess up inlining. There must be a way to turn them off. I propose macros `debug_assert!` and `assert!`. For test cases, `assert!` should be used.

# Motivation

Asserts are too expensive in release builds.

# Detailed design

There should be two macros, `assert!(EXPR)` and `enforce!(EXPR)`. In debug builds (without `--cfg ndebug`), `assert!()` is the same as `enforce!()`. In release builds (with `--cfg ndebug`), `assert!()` compiles away to nothing. The definition of `enforce!()` is `if (!EXPR) { fail!("assertion failed ({}, {}): {}", file!(), line!(), stringify!(expr) }`
There should be two macros, `debug_assert!(EXPR)` and `assert!(EXPR)`. In debug builds (without `--cfg ndebug`), `debug_assert!()` is the same as `assert!()`. In release builds (with `--cfg ndebug`), `debug_assert!()` compiles away to nothing. The definition of `assert!()` is `if (!EXPR) { fail!("assertion failed ({}, {}): {}", file!(), line!(), stringify!(expr) }`

# Alternatives

Other designs that have been considered are using `assert!` in test cases and not providing `enforce!`, but this doesn't work with separate compilation.
Other designs that have been considered are using `debug_assert!` in test cases and not providing `assert!`, but this doesn't work with separate compilation.

There has been an issue raised that `enforce!` is unintuitive for test cases, but I think all workarounds for this are worse because they add complexity.

The impact of not doing this is that `assert!` will become expensive, prompting people will write their own local `assert!` macros, duplicating functionality that should have been in the standard library.
The impact of not doing this is that `assert!` will be expensive, prompting people will write their own local `debug_assert!` macros, duplicating functionality that should have been in the standard library.

# Unresolved questions

Expand Down

0 comments on commit c986337

Please sign in to comment.