Date: Fri, 16 Feb 2024 09:09:37 +0000
On Thu, 15 Feb 2024, 22:12 Jan Schultke via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> I agree that C++ should have widening/overflow functions, and at least
> LEWG-I seems to think of it favorably as well. The devil lies entirely
> in the details though.
>
> Firstly, I strongly oppose returning std::tuple and I suspect the
> committee will see it the same way. The style of returnings pairs or
> tuples has been phased out, and I don't think it's going to make a
> comeback with this paper. It degrades code quality too much not to
> have meaningful names and makes the potential for misuse too great.
>
> > template<class T>
> > [[nodiscard]] constexpr std::tuple<T, T> mul_wide(T, T) noexcept;
>
> How is the user supposed to know which T is meant to store the high
> bits, and which one the low bits? The potential for mistakes is too
> great. It doesn't help that you subsequently do std::get<0> to access
> one of the members. Or alternatively, you use structured bindings,
> however, both of the following declarations are valid:
>
> > auto [lo, hi] = std::mul_wide(...);
> > auto [hi, lo] = std::mul_wide(...);
>
This is of course still true with a named struct with named members.
Nothing stops you from getting the order wrong.
(I think I've requested a compiler warning about that though.)
std-proposals_at_[hidden]> wrote:
> I agree that C++ should have widening/overflow functions, and at least
> LEWG-I seems to think of it favorably as well. The devil lies entirely
> in the details though.
>
> Firstly, I strongly oppose returning std::tuple and I suspect the
> committee will see it the same way. The style of returnings pairs or
> tuples has been phased out, and I don't think it's going to make a
> comeback with this paper. It degrades code quality too much not to
> have meaningful names and makes the potential for misuse too great.
>
> > template<class T>
> > [[nodiscard]] constexpr std::tuple<T, T> mul_wide(T, T) noexcept;
>
> How is the user supposed to know which T is meant to store the high
> bits, and which one the low bits? The potential for mistakes is too
> great. It doesn't help that you subsequently do std::get<0> to access
> one of the members. Or alternatively, you use structured bindings,
> however, both of the following declarations are valid:
>
> > auto [lo, hi] = std::mul_wide(...);
> > auto [hi, lo] = std::mul_wide(...);
>
This is of course still true with a named struct with named members.
Nothing stops you from getting the order wrong.
(I think I've requested a compiler warning about that though.)
Received on 2024-02-16 09:10:54