microsoft/BosqueLanguage

Debug vs Release time checks

demamoh opened this issue · 1 comments

Hello @mrkmarron,

I have been experimenting with the language, and wanted to understand the thinking behind disabling some checks like assert when built with release? Isn't safety lost when built with release, if otherwise not having some of the verification code not being prefixed with release?

I do see one of the posted reasons is a better performance optimization, but I'm more so trying to understand if there is a safety tradeoff. Also, prefixing checks like preconditions with release seems to have the same level of intent as writing that precondition code in the first place. Meaning you wouldn't have written that verification code, to begin with, if you didn't want the code to build in all compiler levels (my understanding is that release is an end state build that most builds will end up at, more like a production build).

Also, from experimenting, I have found that class invariants are checked even when built with release are there special scenarios where invariants would be disabled?

Hi, the view we have is that asserts can have multiples uses in an piece of code. Sometimes they are used to ensure that a bad thing never happens and should always be checked. Other times they are used to document intents or as sanity checks and, in these cases, you might not care about having them enabled in production. Also there is the persistent issue with how expensive an assertion is to check at runtime.

With the current design it is possible to write a ton of assertion code so that bugs can be found quickly at test/debug time but it is easy to make sure that only the very important checks remain enabled in any release (or production) builds.