From c9863370fed4e3e8159d988297781eb7a0e628fc Mon Sep 17 00:00:00 2001 From: Patrick Walton Date: Thu, 1 May 2014 19:01:31 -0700 Subject: [PATCH] Update to reflect what was decided --- active/0000-assert.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/active/0000-assert.md b/active/0000-assert.md index bde3011865a85..d100348980baf 100644 --- a/active/0000-assert.md +++ b/active/0000-assert.md @@ -4,7 +4,7 @@ # 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 @@ -12,15 +12,13 @@ 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