CaseyCarter
commented
1 year ago The only claimed benefit is allowing the uninitialized_xxx algorithms to create objects in const storage (including overwriting objects declared as const which is usually UB). The caller should be responsible for using const_cast if that's really desirable.
The claimed benefit is allowing the uninitialized_xxx algorithms to create objects of const and/or volatile type, which they cannot otherwise do since they deduce the type of object to be created from the reference type of the pertinent iterator. Creating const objects has some (marginal?) benefits over using const pointers to mutable objects. For example, their non-mutable members cannot be modified via casting away const without undefined behavior. A unit test might take advantage of this behavior to force a compiler to diagnose such undefined behavior in a constant expression.
LEWG is welcome to relitigate this decision every Standard cycle if they like, but perhaps someone should record the facts in a paper so we don't need to re-establish them every three years.
brycelelbach
jwakely
JeffGarland
The "voidify" helper breaks const-correctness, for no tangible benefit. C++20 ballot comment US 215 also suggested removing it, but failed to achieve consensus. That should be reconsidered.
The only claimed benefit is allowing the uninitialized_xxx algorithms to create objects in const storage (including overwriting objects declared as const which is usually UB). The caller should be responsible for using const_cast if that's really desirable. Implicitly removing 'const' is unsafe and unnecessary.
Remove "voidify" throughout Clause 27. Use
static_cast<void*>(addressof(x))instead.