From 0580a69ccae89e9ad88b7da3c373b6d33bcf1f6a Mon Sep 17 00:00:00 2001 From: Patrick Walton Date: Fri, 18 Apr 2014 10:42:34 -0700 Subject: [PATCH 1/2] Add RFC for disablable assertions --- active/0000-assert.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 active/0000-assert.md diff --git a/active/0000-assert.md b/active/0000-assert.md new file mode 100644 index 00000000000..bde3011865a --- /dev/null +++ b/active/0000-assert.md @@ -0,0 +1,27 @@ +- Start Date: 2014-04-18 +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + +# 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. + +# 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) }` + +# 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. + +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. + +# Unresolved questions + +None. From c9863370fed4e3e8159d988297781eb7a0e628fc Mon Sep 17 00:00:00 2001 From: Patrick Walton Date: Thu, 1 May 2014 19:01:31 -0700 Subject: [PATCH 2/2] 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 bde3011865a..d100348980b 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