Date: Fri, 27 May 2022 18:04:48 +0300
>
> The C-style cast and reinterpret_cast are not the same. A C-style cast
> can perform a static_cast and const_cast; a reinterpret_cast can perform
> the identity conversion but after that performs conversions that cannot
> appear in constant evaluation.
>
C-cast has multiple stages and some of them are allowed in constexpr
context. reinterpret_cast also has multiple stages but none of them are
allowed in constexpr, what's the logic here? Why is the same conversion
allowed with one syntax and not with the other?
If your argument is that reinterpret_cast as identity conversion should be
> allowed to appear in constant evaluation, that might make sense, but it's
> hard to see that as much of an improvement over being explicit with if
> constexpr. That is, it's beneficial reading the code to see when it will
> perform the weaker, safer operation.
>
Not only identity but all conversions that are allowed for C-cast in
constexpr context. I see your point but honestly I can hardly imagine
anyone will write if-constexpr or explicitly two versions of such a
function using enable-if in pre-C++17 when a simple C-cast does the work.
On Fri, May 27, 2022 at 5:45 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:
> On Fri, 27 May 2022 at 08:28, Oleksandr Koval <
> oleksandr.koval.dev_at_[hidden]> wrote:
>
>> Why not use if constexpr?
>>>
>> Because then it's not a generic code anymore, it's a workaround around an
>> artificial constraint. Isn't it silly that people are forced to use bad old
>> C-cast instead of C++ construction just because something is prohibited
>> without a reason?
>>
>
> The C-style cast and reinterpret_cast are not the same. A C-style cast can
> perform a static_cast and const_cast; a reinterpret_cast can perform the
> identity conversion but after that performs conversions that cannot appear
> in constant evaluation.
>
> If your argument is that reinterpret_cast as identity conversion should be
> allowed to appear in constant evaluation, that might make sense, but it's
> hard to see that as much of an improvement over being explicit with if
> constexpr. That is, it's beneficial reading the code to see when it will
> perform the weaker, safer operation.
>
> The C-style cast and reinterpret_cast are not the same. A C-style cast
> can perform a static_cast and const_cast; a reinterpret_cast can perform
> the identity conversion but after that performs conversions that cannot
> appear in constant evaluation.
>
C-cast has multiple stages and some of them are allowed in constexpr
context. reinterpret_cast also has multiple stages but none of them are
allowed in constexpr, what's the logic here? Why is the same conversion
allowed with one syntax and not with the other?
If your argument is that reinterpret_cast as identity conversion should be
> allowed to appear in constant evaluation, that might make sense, but it's
> hard to see that as much of an improvement over being explicit with if
> constexpr. That is, it's beneficial reading the code to see when it will
> perform the weaker, safer operation.
>
Not only identity but all conversions that are allowed for C-cast in
constexpr context. I see your point but honestly I can hardly imagine
anyone will write if-constexpr or explicitly two versions of such a
function using enable-if in pre-C++17 when a simple C-cast does the work.
On Fri, May 27, 2022 at 5:45 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:
> On Fri, 27 May 2022 at 08:28, Oleksandr Koval <
> oleksandr.koval.dev_at_[hidden]> wrote:
>
>> Why not use if constexpr?
>>>
>> Because then it's not a generic code anymore, it's a workaround around an
>> artificial constraint. Isn't it silly that people are forced to use bad old
>> C-cast instead of C++ construction just because something is prohibited
>> without a reason?
>>
>
> The C-style cast and reinterpret_cast are not the same. A C-style cast can
> perform a static_cast and const_cast; a reinterpret_cast can perform the
> identity conversion but after that performs conversions that cannot appear
> in constant evaluation.
>
> If your argument is that reinterpret_cast as identity conversion should be
> allowed to appear in constant evaluation, that might make sense, but it's
> hard to see that as much of an improvement over being explicit with if
> constexpr. That is, it's beneficial reading the code to see when it will
> perform the weaker, safer operation.
>
-- Regards, Oleksandr Koval.
Received on 2022-05-27 15:05:05