Subject: What's going on with non-transient constexpr allocations?
From: Brian Bi (bbi5291_at_[hidden])
Date: 2019-06-10 14:27:19
I was told that the reason why non-transient allocations failed to make it
into C++20 is the "vector<unique_ptr<int>> problem" - i.e., if you have
constexpr std::vector<std::unique_ptr<int>> V = ...;
then the language doesn't have a mechanism to stop you from modifying the
values that the elements of V point to. Later I was told that Daveed thinks
he knows how to solve this problem by introducing some sort of transitive
constness into the language, though of course something like this will have
to wait for C++23 or later.
Can someone flesh out this picture for me a bit more? Why is the problem a
problem that needs to be solved in the first place? i.e., what breaks in
the language if we just say: yes, you can modify *V[i]? Indeed, P0784R5
seems to recognize that having constexpr allocations be mutable can be
useful, as long as the destructor doesn't read any values that have been
modified. If that's the case, why is transitive constness needed?
-- *Brian Bi*
STD-DISCUSSION list run by firstname.lastname@example.org
Older Archives on Google Groups