On 16/02/2024 10:09, Jonathan Wakely via Std-Proposals wrote:
> 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.

It's however not true if one doesn't use a structured binding.


The paper is *already* spelling out the definition of each return type.

For instance, when it says something like:

> outputting:
>
> low_result :T - the low bits of result with the same width of T
> borrow :bool - a bool flag that is set to true if low_result does not represent the value of result (i.e. overflow)

that's the definition (in prose) of the return type for sub_borrow:

> template <class T> struct sub_borrow_result {
> T low_result; // <-- from the paper
> bool borrow;
> };


And this allows users to use these results unambiguously:

> auto v = std::sub_borrow(...);
> if (!v.borrow)
> use (v.low_result);


Unambiguous usage *never* happens with pairs and tuples where the data
members are meaningless (pair) or the burden of finding good names (and
the risk of screw-ups) is always pushed onto the final user.

Thank you,

-- 
Giuseppe D'Angelo