WG21-N4885 [specialized.algorithms.general]/4 says that the uninitialized_meow family of algorithms is powered by an exposition-only voidify helper, which has the interesting property of returning modifiable void*. Surprisingly, this intentionally handles destinations that are iterator-to-const, allowing const elements to be constructed in uninitialized memory.
We should add test coverage for this scenario, for all of the uninitialized_meow algorithms that are affected. This may require reworking internal machinery like _Ptr_copy_cat/_Ptr_move_cat. Finally, we should ensure that we don't disrupt the plain meow algorithms, which should not be allowed to modify through iterator-to-const (as they aren't specified with voidify).
Noticed while reviewing #1772, but filed as a separate issue as this is pre-existing, non-trivial, and largely unrelated to that PR's scope.
WG21-N4885 [specialized.algorithms.general]/4 says that the
uninitialized_meowfamily of algorithms is powered by an exposition-onlyvoidifyhelper, which has the interesting property of returning modifiablevoid*. Surprisingly, this intentionally handles destinations that are iterator-to-const, allowing const elements to be constructed in uninitialized memory.We should add test coverage for this scenario, for all of the
uninitialized_meowalgorithms that are affected. This may require reworking internal machinery like_Ptr_copy_cat/_Ptr_move_cat. Finally, we should ensure that we don't disrupt the plainmeowalgorithms, which should not be allowed to modify through iterator-to-const (as they aren't specified withvoidify).Noticed while reviewing #1772, but filed as a separate issue as this is pre-existing, non-trivial, and largely unrelated to that PR's scope.