Skip to content

Conversation

@outputenable
Copy link
Contributor

Though maybe I've misunderstood the purpose of the "debug" feature?

Using `debug_assertions` seems to be the officially recommended way to
conditionally "enable extra debugging code in development but not in
production", see

* The Rust Reference, Conditional Compilation
  https://doc.rust-lang.org/reference/conditional-compilation.html#r-cfg.debug_assertions
* How to check release / debug builds using cfg in Rust?
  https://stackoverflow.com/a/39205417

Hopefully this is in the spirit of the original code.
This should help prevent typos like the one fixed in
249f497 .
@thequux
Copy link
Contributor

thequux commented Nov 25, 2025

In hindsight, I probably should have called the feature "no_unsafe"; IIRC, that's the only unsafe code in the crate and we foresaw use cases in which it would be preferable to not use unsafe code at all. With that said, that particular bit of unsafe code should be practically safe by construction, so using debug_assertions is probably preferable.

Do not conditionally execute either safe or unsafe code, but enable an
additional check for development.
@outputenable
Copy link
Contributor Author

Ah I see, yes with that name (and intention) the feature makes sense. I agree with you though and think that unsafe is fine here, and would enable additional checks for debugging only. With this in mind I just pushed a simpler version that is basically just a debug_assert!(). If you actually want the "no_unsafe" feature then the checking code could maybe also be enabled for development builds, e.g.

$ if cfg!(any(feature = "no_unsafe", debug_assertions)) { ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants