On Mon, 26 Apr 2021 at 20:18, Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
> > > This has not much to do with array types: It is the
> > > same for functions and can easily be avoided
> > > using typeof when it becomes too complex.
> >
> > You need a typedef for every function declaration that uses an array as a return
> > type. Or, like P1997 suggests, you need to use a trailing return type.
>
> It is the same for functions returning function pointers:
>
> int (*foo1(int a))(int);
>
> int (*foo2(int a))[3];

Sure. In C++, we just use std::function instead, and don't require our
users to learn the spiral rule.

> But it is not something which comes up often and
> typedef is then not really too difficult.
>
> typedef int Array3[3];
> Array3 *foo2(int a);
>
> Or one uses typeof:
>
> typeof(int[3]) *foo2(int a);

Pretty please. We are not going to suggest C++ users to do that on all
the millions of C++ projects;
we can't realistically standardize a useful set of such typedefs, so
in order to write a simple
declaration that looks like
std::array<int, 3> foo2(int);
we just.. ..let them write that declaration.

> Which could also be a macro:

Oh come on.

> Trailing return types would also make this regular.

At the cost of requiring trailing return types to be used. That seems
like a draconian requirement,
when in general
T foo(U);
will just work.

> > That's not what I'd call regular.
> I agree it is strange syntax and I agree it should
> be improved (and a simple macro is completely
> sufficient to get regular syntax if necessary).
> But all this has not much to do with the type as such.

Well, it has everything to do with the type; how to use the type, specifically.


> Assume I want to simple write a function that transposes
> a 2D matrix. In C99 it has this simple prototype:
>
> void transpose(int A, int B, double o[B][A], const double i[A][B]);
>
> How do you write this in C++ (23?) ?

std::mdspan<int, std::extents<2, std::dynamic_extent>>
transpose(const std::mdspan<int, std::extents<2, std::dynamic_extent>>& input);

Sure, fine, maybe we would like to entertain standardizing an extent
type for 2d-dynamic. :P