LWG-3561 Issue with internal counter in `discard_block_engine`

[MattStephanson]

LWG-3561 Issue with internal counter in discard_block_engine

Discussion from the meta-issue #2236:

• Matt Stephanson (@MattStephanson)

  LWG-3561: This would involving changing discard_block's internal _Nx counter and template arguments from int to size_t, which I think would be an ABI break. I think the most we could do now is add a // TRANSITION, ABI comment, and maybe a static_assert for discard_block_engine that its parameters must be <= INT_MAX.

• Casey Carter (@CaseyCarter)

  I think we could greatly improve discard_block_engine by divorcing it completely from the TR1-era discard_block. We could even make it tolerate p > INT_MAX, but I agree that r > INT_MAX is not supportable without breaking ABI.

• timsong-cpp

  Couldn't you change the type of _Nx only if r > INT_MAX?
  Edit: looks like MSVC doesn't check narrowing from size_t to int in the NTTP, hmm...is it an ABI break if the existing thing compiles but totally doesn't work?

[MattStephanson]

Couldn't you change the type of _Nx only if r > INT_MAX?

That's an interesting idea. I can see how that might work, but it would require not just _Nx but also discard_block's NTTPs to be dependent as well (or unconditionally size_t). I don't know if that has ABI implications..

is it an ABI break if the existing thing compiles but totally doesn't work?

Not necessarily, I think, but existing object files where discard_block is instantiated with negative parameters still have to link, even if their implementation is broken. Presumably the existing objects already contain at least one definition, since it's inline, so maybe it's unnecessary for new code to handle such cases?

[frederick-vs-ja]

Can we change the base class of discard_block_engine when r > INT_MAX?