`<ranges>`: `iota_view` and `_Counted_fn` inconsistently use `_STL_ASSERT` for precondition checking

[frederick-vs-ja]

Currently, there're two styles of precondition checking in <ranges>.

1. _STL_ASSERT, used only by iota_view and _Counted_fn.
2. _STL_VERIFY guarded by _CONTAINER_DEBUG_LEVEL > 0.
3. _STL_VERIFY guarded by _ITERATOR_DEBUG_LEVEL != 0.

It's unclear to me why there're both != 0 and > 0.

It seems that "_STL_VERIFY guarded by _ITERATOR_DEBUG_LEVEL != 0" is intendedly used for iterator-related checking, and "_STL_VERIFY guarded by _CONTAINER_DEBUG_LEVEL > 0" and _STL_ASSERT are used for other preconditions.

Should we consistently use one style for checking preconditions that are not directly related to iterators?

[CaseyCarter]

The answer isn't <ranges>-specific, we use the same precondition conventions STL-wide.

It's unclear to me why there're both != 0 and > 0.

The reasons are historical. _ITERATOR_DEBUG_LEVEL is either 0 (no iterator debugging), 2 (full iterator debugging), or 1 (archaic quasi-deprecated "some debugging" state). It's almost always tested as _ITERATOR_DEBUG_LEVEL != 0.

When _CONTAINER_DEBUG_LEVEL was added, we envisioned it growing into a spectrum of "concentric" levels, with increasing levels requesting more expensive kinds of checks. _CONTAINER_DEBUG_LEVEL == 0 is only for O(1) checks that don't affect object representation. It made sense at the time that we use > for all _CONTAINER_DEBUG_LEVEL tests so _CONTAINER_DEBUG_LEVEL >0 would be consistent with _CONTAINER_DEBUG_LEVEL > 2. Additional levels were never added: we have serious concerns about this feature and its ODR consequences. You really don't want your security feature to be silently disabled by linking with some third-party library that was built without said feature enabled.

We use _STL_ASSERT when we want a precondition checked only when _DEBUG is non-zero. _DEBUG != 0 implies _CONTAINER_DEBUG_LEVEL > 0, but the reverse is not true; users can define _CONTAINER_DEBUG_LEVEL to something non-zero in release builds. _ITERATOR_DEBUG_LEVEL defaults to 0 when _DEBUG == 0, and 2 when _DEBUG != 0. Users can define _ITERATOR_DEBUG_LEVEL or _CONTAINER_DEBUG_LEVEL themselves to override the defaults, but notably we only ship DLLs supporting _DEBUG == 0 && _ITERATOR_DEBUG_LEVEL == 0 and _DEBUG == 1 && _ITERATOR_DEBUG_LEVEL == 2.

How do I choose?

• A check that depends on the iterator-debugging machinery must obviously be guarded with _ITERATOR_DEBUG_LEVEL. Verification that two list<float>::iterators are from the same list is a good example.
• An O(1) check that can be performed regardless of representation should be guarded with _CONTAINER_DEBUG_LEVEL. Bounds checking in vector::operator[] would be the canonical example.
• Other checks should be guarded with _DEBUG, possibly by using _STL_ASSERT. These tend to be checks that don't need the iterator debugging info and have a complexity greater than O(1) but not greater than the complexity of the operation with the precondition. There are no checks in the STL with asymptotic complexity greater than the operation they guard because such checks generally make the library unusable.

We notable also have different controls for precondition checks on internal functions that are only enabled when running the STL test suite, but that's a different issue than enforcing preconditions on user-supplied function arguments so I won't detail them here.

[frederick-vs-ja]

• An O(1) check that can be performed regardless of representation should be guarded with _CONTAINER_DEBUG_LEVEL. Bounds checking in vector::operator[] would be the canonical example.

Sounds like that we should also use _CONTAINER_DEBUG_LEVEL-guarded checks in iota_view and _Counted_fn, because the preconditions are checked by O(1) comparisons, right?

STL/stl/inc/ranges

Lines 1384 to 1387 in 9aca224

	if constexpr (totally_ordered_with<_Wi, _Bo>) {
	_STL_ASSERT(_Value_ <= _Bound, "Per N4950 [range.iota.view]/6, the first argument must not exceed the "
	"value-initialized bound when their types are totally ordered.");
	}

STL/stl/inc/ranges

Lines 1393 to 1396 in 9aca224

	if constexpr (totally_ordered_with<_Wi, _Bo>) {
	_STL_ASSERT(_Value_ <= _Bound_, "Per N4950 [range.iota.view]/8, the first argument must not exceed the "
	"second when their types are totally ordered.");
	}

STL/stl/inc/ranges

Line 5254 in 9aca224

_STL_ASSERT(_Count >= 0, "The size passed to views::counted must be non-negative");

[StephanTLavavej]

A. Jiang (@frederick-vs-ja) Yep, that sounds correct to us (discussed at the weekly maintainer meeting).