<deque>: Use _Next_iter and _Prev_iter

[CaseyCarter]

Fixes DevCom-1134328 / AB#1166791.

[BillyONeal]

I don't really have any sympathy for this in the same way we didn't have sympathy for that user who reported a 'vector does ADL things in its dtor requiring more things to be complete than are otherwise needed' before.

But the mitigation is cheap so why not.

[StephanTLavavej]

I wonder if we should have a more comprehensive test (like our Evil class with overloaded operator, and operator&), given that this code seems to be conformant and there could be issues elsewhere in the STL especially during future refactoring, but certainly this is a strict improvement over the status quo. Perhaps we should file a test issue to further enhance coverage.

[BillyONeal]

@StephanTLavavej The difference is that unlike the &/, situation, there's nothing we can really do to guard against this kind of ADL-injected-ill-formed problem in the general case. For example, allowing this in general would prohibit calling any standard library algorithms from any of the containers, because the algorithms have expressions like iter+42 inside which are vulnerable in the same way this is vulnerable. Even if the spec doesn't require this right now I think we should fix the spec to prohibit and behave as if the spec does prohibit such ADL hijacking of operators when neither of the operands are a program-defined type (here, _Deque_iterator and int).

[CaseyCarter]

Formally iter+42 is allowed only if iter is a random-access iterator whose difference type is int. We guard against this in the general case by only adding or subtracting values of an iterator's difference type (ignoring cv-qualifiers) to an iterator. We've been very careful about the types of variables that we add and subtract from iterators, but not so much with literals.

[BillyONeal]

Formally iter+42 is allowed only if iter is a random-access iterator whose difference type is int.

Would that have protected against this particular case?

[CaseyCarter]

Formally iter+42 is allowed only if iter is a random-access iterator whose difference type is int.

Would that have protected against this particular case?

Yes. The syndrome here is that we have two functions:

struct S {
  template <class T> S(T&&); // Everything converts to S
};

void f(S, int);              // Unintentional ADL-hijacking function
void f(iterator, ptrdiff_t); // Actual function we want to call

and we're evaluating f(iterator{}, 1) with an iterator whose difference type is ptrdiff_t. This works as we intend in 32-bit compiles - where ptrdiff_t is int - but not in 64-bit compiles when it's long long. Our f has a better ICS (implicit conversion sequence) for the first argument - exact match - but the user f has a better ICS for the second argument - again exact match. Overload resolution is ambiguous. f(iterator{}, ptrdiff_t{1}) would unambiguously call the correct function.

[StephanTLavavej]

Thanks for investigating and fixing this surprising bug! I never would have thought that an STL container couldn't say iter + 1 for its own iterators.