You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
The text was updated successfully, but these errors were encountered:
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?
LWG-3561 Issue with internal counter in
discard_block_engine
Discussion from the meta-issue #2236:
The text was updated successfully, but these errors were encountered: