niedz., 8 gru 2024 o 14:42 Jonathan Wakely <cxx_at_[hidden]> napisał(a):
>
>
>
> On Sun, 8 Dec 2024, 12:51 Marcin Jaczewski via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>>
>> niedz., 8 gru 2024 o 12:04 F. v.S. via Std-Proposals
>> <std-proposals_at_[hidden]> napisał(a):
>> >
>> > Hi!
>> >
>> > This is a known LWG issue which has been resolved: https://cplusplus.github.io/LWG/issue3870.
>> >
>> > If you use the latest libc++ (Clang 20 trunk), the latest libstdc++ (GCC 15 trunk), or MSVC STL since VS 2022 17.7, the casting-away-constness use of construct_at will be error.
>> >
>> > Thanks,
>> > F.v.S.
>> >
>>
>> And `a.~T()` is still legal? Should here const cast be required too?
>
>
> No, you can always destroy const objects, otherwise you couldn't define { const T a; } because the implicit destruction would not be allowed.
>
> You can also use a const T* as the operand of a delete expression.
>
>

My mental model looked like:

As neither constructor or destructor can be `const` I always interpreted that
`delete` do `const_cast` before calling destructor on objects in that memory.
Same with the destructor itself, before calling object members
destructors, it uses this cast too.
As both "own" this memory storage that will soon be released,
they are allowed to do this cast.

But as I see it, I probably need to update my metal mode to better
match the standard.