Date: Wed, 24 Aug 2022 09:15:26 +0200
On 23/08/2022 23.18, Tom Honermann via SG16 wrote:
> As specified, the operations do not end the lifetime of, nor change the type of, the array objects that hold the sequence of elements that are being converted. This creates the strange result that, for example, an array object of type char16_t could have elements of type wchar_t. I'm not sure if that is ok from a core language perspective or not, but it seems problematic to me.
That's an interesting observation.
So, if the array gets destroyed (for example, because it is automatic
and we're hitting the end of the block), we'll attempt to destroy
objects of type char16_t, although the actual elements are of type
wchar_t.
Given that we've recently moved to trivial destruction being
"almost the same" as non-trivial destruction, that feels like
it ought to be undefined behavior, which is scary.
Is "start_lifetime_as" sufficient for the use-case
(but possibly not optimally-convenient to use)?
Jens
> As specified, the operations do not end the lifetime of, nor change the type of, the array objects that hold the sequence of elements that are being converted. This creates the strange result that, for example, an array object of type char16_t could have elements of type wchar_t. I'm not sure if that is ok from a core language perspective or not, but it seems problematic to me.
That's an interesting observation.
So, if the array gets destroyed (for example, because it is automatic
and we're hitting the end of the block), we'll attempt to destroy
objects of type char16_t, although the actual elements are of type
wchar_t.
Given that we've recently moved to trivial destruction being
"almost the same" as non-trivial destruction, that feels like
it ought to be undefined behavior, which is scary.
Is "start_lifetime_as" sufficient for the use-case
(but possibly not optimally-convenient to use)?
Jens
Received on 2022-08-24 07:15:32