Expects/Ensures revision

[hsutter]

This PR does the following:

• Removes __builtin_expect branch prediction assistance, which in strict_not_null performance issues with reference types #930 was measured to be useless or a small pessimization.
• Removes GSL_ASSUME which was unused and is not mentioned in the C++ Core Guidelines which defines GSL.
• Reinstates GSL_UNENFORCED_ON_CONTRACT_VIOLATION and GSL_TERMINATE_ON_CONTRACT_VIOLATION (the latter is still the default)
• Replaces GSL_CONTRACT_CHECK with a general contract_group, and parameterizes Expects and Ensures with a group.

The last is the main change. Each contract_group object wraps one handler, "terminate_handler" style. Making each one an object allows controlling violation handlers separately for different groups of contracts, notably Bounds and Null checks -- now GSL users who want Bounds violations to always fail-fast can enforce that only those violations do always fail-fast, and independently can configure whether Null violations should fail-fast. The default violation action for each group is currently set to be terminate, but can be configured to do nearly anything by customizing set_handler -- for example, gsl.Bounds.set_handler( []{ my_custom_logger.LogAndContinue("out of bounds access detected"); } );.

The only restriction on the violation handler is that it must be noexcept. This intentionally prevents installing throwing violation handlers, because those are not meaningful in general: Whether a given function wants to write Expects/Ensures contracts for debugging purposes, and/or the same function can never fail and therefore wants to also be noexcept at run time, are orthogonal and independent issues, and in the case of a function that does both it is not useful to throw an exception from an Expects/Ensures violation because it will just hit the function's noexcept, so installing a throwing violation handler is just a fancy way of installing a handler that calls terminate.

I've done performance tests at -O1 and have not been able to measure an overhead to doing this if (!b) call_handler(); test that is not in the range of instruction alignment issues. That is, in the few tests where I could measure a slight overhead (or speedup!) to inserting the Expects or Ensures check, I was able to erase the difference by adding a nop (asm(nop);), for example here: https://quick-bench.com/q/PqA9EPJqUOwp51iql4NKUDEpsUg . So at least so far it appears there is zero cost to the predictable branch and the only overhead is the extra instructions.

More performance testing is welcome -- in particular, @JordanMaples please try this branch vs. the current implementation in any existing span performance tests you have and see if there's a measurable overhead on span bounds checking now that the span bounds check would invoke a user-customizable violation handler on failure.

This PR intends to address several open issues:

• Checks in not_null. #604
• gsl::not_null can't be anymore zero cost abstraction. #877
• strict_not_null performance issues with reference types #930
• Allow to disable MSVC exception workaround #936

[JordanMaples]

Do we want to add an Expects(cond) and Ensures(cond) to prevent outright breaking users who have Expects/Ensures in their code or are we willing to make this a breaking change?

[mbeutel]

Is this extension of Expects()/Ensures() backed by a proposed change in the Core Guidelines?

[hsutter]

Before this PR is accepted, it needs to be reviewed by the Guidelines editors.

Summarizing the current status and plan: Right now, we (Microsoft) are first doing a performance test in some internal code that heavily uses GSL (particularly but not only gsl::span) to validate that this proposed change doesn't cause measurable perf overhead. If that efficiency is not validated, there's no point in bothering the Guidelines editors with a non-starter and we should just reject this PR. If it is validated, then the next step is to have the design reviewed by the Guidelines editors and see if they agree, agree with changes or other feedback, or reject it.

[mbeutel]

Thank you, that is helpful context.

Why do you want to make contract enforcement strictly a runtime decision instead of sticking with the traditional preprocessor-based approach (conditional definition of Expects()/Ensures())? I understand you want to support different handlers for different contract groups; but that could also be done with the preprocessor.

[hsutter]

@mbeutel Sorry for the delay in replying. Re this:

Why do you want to make contract enforcement strictly a runtime decision instead of sticking with the traditional preprocessor-based approach (conditional definition of Expects()/Ensures())?

We have some customers who want one or both of:

1. Be able to use span in different parts of the same program, some of which have checking on and checking off, without ODR violations. span does it checking via Expects, and having macros change the definition of Expects in a single span implementation creates ODR issues. We considered other approaches, such as having checked and unchecked span types, but then that defeats composability for a vocabulary types.

2. Be able to guarantee certain uses of Expects are always checked (notably, to guarantee that bounds checks are always performed and violations always fail-fast), regardless of whether the same program contains other uses of Expects that may not be checked or may be checked but handled differently.

[mbeutel]

@hsutter No problem, thanks for taking the time to explain.

Be able to use span in different parts of the same program, some of which have checking on and checking off

How would that work? How would gsl::span<> know that checks are desired in the current part of the program? The only thing that comes to mind is global state, i.e. you install a contract violation handler when entering the part of the program that desires checks and you restore the previous handler upon leaving.

We considered other approaches, such as having checked and unchecked span types

(...e.g. gsl::span<> and std::span<>...)

that defeats composability for a vocabulary types

Could you elaborate on that concern? I understand that bifurcation of vocabulary types can be problematic, the prime example being std::vector<> and std::pmr::vector<>. But spans are mostly used at function interfaces, and different span types should be constructible from each other through the contiguous-range constructor.

Be able to guarantee certain uses of Expects are always checked (notably, to guarantee that bounds checks are always performed and violations always fail-fast), regardless of whether the same program contains other uses of Expects that may not be checked or may be checked but handled differently.

I agree that it would be desirable to have some granularity in the enforcement of precondition/postcondition checks, and I like the idea of contract groups.

Sometimes it's easier to assess how expensive and how useful a check will be than which group it would belong to. Some of the Contracts proposals had floated the idea of audit-level checks, which had inspired me to add different severity-level flavors of Expects() to gsl-lite:

• gsl_Expects(): on by default
• gsl_ExpectsDebug(): like assert(), this is not evaluated if NDEBUG is defined
• gsl_ExpectsAudit(): off by default

Contract groups could be orthogonal to severity, and I can see how configuring different violation behaviors for different contract groups might be useful. E.g. one might want to terminate on safety-related violations but only emit a log message for violations of program logic.