Moritz Beutel

> However, I.6 also recommends `Expects` for general use, some of which may want a continuation mode, we welcome example cases of such uses on this thread. (*Edit:* you asked...

The point of `GSL_THROW_ON_CONTRACT_VIOLATION` is testability. You want to be able to test that your function detects a precondition violation, and that is cumbersome if the function aborts the program....

> > > > @MikeGitb ... which it did with GSL_UNENFORCED_ON_CONTRACT_VIOLATION up until this recent policy change. > > Are you sure? If I have a 5 element view over...

Perhaps the easiest way of getting better diagnostics for precondition/postcondition checks would be to implement them with [`assert()`](https://en.cppreference.com/w/cpp/error/assert), for which the standard states the following requirements (emphasis mine): > If...

Somewhat related issue: right now CppCoreCheck seem to hard-code some GSL type names such as `gsl::span`, `gsl::not_null`, `gsl::owner` (cf. https://github.com/gsl-lite/gsl-lite/issues/240). If GSL implementations were encouraged to use their own namespace...

It isn't: it doesn't yet support fixed-size spans, it has operations that were deliberately left out for `std::span` (e.g. comparison), and some small things are missing or named differently. I...

> If you want to have a cast with a narrow contract (terminating when the input value can't be represented by the output type), narrow_cast would be the appropriate function...

So if we get rid of `narrow()` and `narrow_cast()` (by removing them from the Core Guidelines and deprecating them in the GSL implementations), what do we replace them with? I...

> Regarding bugs vs recoverable errors: [...] This is a much more general issue. The Core Guidelines currently specify that the program be terminated if preconditions expressed with `Expects()` are...

I think narrowing from, say, `double` to `float` and suffering failure on loss of precision is an extremely, um, narrow use case; I'd be hard pressed to come up with...