>I'm uncomfortable with the idea of a class author being able to override
>the user's choice to *not* declare a local variable [[indeterminate]], by
>placing [[indeterminate]] on the declaration of a non-static data member
>and thus making part of the object's storage indeterminate anyway. Note
>that even if it's just in a private member, there will still be UB if the
>object is used as the source of `memcpy`.
It's the class author's job to do the proper encapsulation. If memcpy is indeed UB (is it really?), then maybe such classes must not be trivially copyable. I agree that it's error prone, but if a class requires some indeterminate storage for efficient operation, then it could be less error prone to implement it correctly once within the class than the user applying [[indeterminate]] at each usage.
My mistake, my earlier message was inaccurate. The `memcpy` itself would not be UB, but examining the resulting `unsigned char` array (or whatever it is) would cause UB.
But I think that it's not UB to use `memcpy` even when the source is a non-trivially-copyable class. We just place no guarantees on what you get. But I don't interpret this as a blanket permission to treat the bytes as indeterminate. In P1839, we use the wording "an unspecified value that is neither indeterminate nor erroneous".
(Now, strictly speaking, storage that is not indeterminate initially could become indeterminate later, e.g., the class's constructor could create an indeterminate array on the stack and then memcpy that array into one of its own members, thus giving the member an indeterminate value. So that means the class author is still ultimately in control, and the user can never be sure whether they're getting indeterminate bytes after construction. But despite that, I think it would be wise not to encourage class authors to give their class members indeterminate values if they didn't initially have them.)