On Sunday, 9 September 2018 at 08:31:49 UTC, John Carter wrote:
> On Sunday, 2 September 2018 at 01:55:53 UTC, Walter Bright wrote:
>> On 9/1/2018 5:47 PM, Nick Sabalausky (Abscissa) wrote:
>>> All in all, John is very non-committal about the whole thing.
>>
>> He probably got tired of arguing about it :-)
>
> Let's face it, the term "assert" has been poisoned by decades of ambiguity.

There is really no ambiguity... The terminology is widespread and well understood across the field I think.

"assume" means that something is taken as a given fact that has already been established by others.

"assert" means that it is something that should be established before shipping.

For contracts:

"expects"  (or "requires") means that the input to a function should have those properties. (precondition)

"ensures" means that the returned value should always have those properties. (postcondition)

Microsoft GSL let you configure pre/post conditions so that you either get terminate, throw or (much more dangerous) assume on contract violations. They don't seem to provide an option for ignoring it.


#if defined(GSL_THROW_ON_CONTRACT_VIOLATION)

#define GSL_CONTRACT_CHECK(type, cond)                                                             \
    (GSL_LIKELY(cond) ? static_cast<void>(0)                                                       \
                      : gsl::details::throw_exception(gsl::fail_fast(                              \
                            "GSL: " type " failure at " __FILE__ ": " GSL_STRINGIFY(__LINE__))))

#elif defined(GSL_TERMINATE_ON_CONTRACT_VIOLATION)

#define GSL_CONTRACT_CHECK(type, cond)                                                             \
    (GSL_LIKELY(cond) ? static_cast<void>(0) : gsl::details::terminate())

#elif defined(GSL_UNENFORCED_ON_CONTRACT_VIOLATION)

#define GSL_CONTRACT_CHECK(type, cond) GSL_ASSUME(cond)

#endif

On Sunday, 9 September 2018 at 06:27:52 UTC, Jonathan M Davis wrote:
> So, maybe what we should do here is take a page from Weka's playbook and add a function that does something like check a condition and then assert(0) if it's false and not try to say that assertions should always be left in production.

That's the easy solution, but in real world development things get more complicated. Say, if you develop a game maybe you want no asserts in your render code, but as many asserts as possible in your game logic code...

 It would make sense to defer some way of control to the calling context. Especially with templated functions in a very generic library that is used across the entire program.

On Sunday, 9 September 2018 at 09:01:28 UTC, Ola Fosheim Grøstad wrote:

>> Let's face it, the term "assert" has been poisoned by decades of ambiguity.
>
> There is really no ambiguity... The terminology is widespread and well understood across the field I think.

Ahh, I so, so wish what you said was true. The endless debates in this forum, and many other forums across the 'net and sadly, in my own workplace, have firmly convinced me...

* The terminology is indeed widespread.
* and well understood across the field
* to mean subtly different and incompatible things to different groups of people.

ie. Yes, everybody knows the words, everybody can read the code, everybody can find somebody who agrees with his intent and meaning.... but get a large enough group together to try agree on what actions, for example, the optimiser should take that are implied by that meaning... and flames erupt.

Suddenly you find people don't actually agree on the intent and meaning of the code.

Communication is hard, human communication is doubly hard.

I beg humanity to give up on that word "assert" and come up with others words and define explicit the intent and meaning and implications.

So much pain will be avoided.

On Sunday, 9 September 2018 at 21:20:11 UTC, John Carter wrote:
> ie. Yes, everybody knows the words, everybody can read the code, everybody can find somebody who agrees with his intent and meaning.... but get a large enough group together to try agree on what actions, for example, the optimiser should take that are implied by that meaning... and flames erupt.

Well, it has less to do with "assert" than with how semantics are assigned to something that should never occur. But it isn't really optimal to hardcode failure semantics in the source code...

Even simple semantics, like whether tests should be emitted in release builds is possibly context dependent, so not really possible to determine with any level of certainty when writing a library reused across many projects.

On Monday, 10 September 2018 at 19:44:22 UTC, H. S. Teoh wrote:
> It's high time we distinguished between the various flavors of assert, preferably with new words to avoid the baggage that has accumulated around 'assert'.

Perhaps we can take some cues from Vigil, the eternally morally vigilant programming language, and use 'implore' for preconditions (aborts on new strict mode, throws by default) and 'swear' for other contracts?