On Mon, 26 Apr 2021 at 22:32, Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
> > > Which could also be a macro:
> > Oh come on.
> Why not? If the syntax is really so much of a problem,
> then a macro would solve this in C as well
> as the std::function or std::array templates do
> in C++.

I really wouldn't want to digress into why macros are bad, but
1) they don't scale
2) they don't obey scope
3) having two different programmers manage to not have incompatible
macro clashes is a miracle

So, the suggestion to paper over problems in declarations with a macro
is a waste of both of our time. ;)

> Of course, in C++ you could also use a template
> instead of a macro:
>
> c_array<int, 3> x; // same type as int[3]

Yeah, funny how we already have std::array that looks like that, and
it just solves this problem, more in the next.

> > 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.
>
> I assume you meant:
>
> std::array<T, N> foo(U);

No. :) I meant that in general, any C++ declaration for an idiomatic
(this part is important) C++ function can be written like
that,
T foo(U);
No trailing return types. No macros, no aliases, no tricks. Write the
return type first, then the name, then the
parameter list. It doesn't matter what those types are. You don't need
the spiral rule. You don't need aliases,
typedefs, or macros to work around the need for the spiral rule.

That's regular.

> > > > 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.
>
> Then we should change the declarator syntax and not
> reinvent the type.

Well, with a reinvented type, the declarator syntax works fine, and we
don't need to invent
new declarator syntaxes. So I'd step very cautiously before agreeing
with that conclusion
of yours about what we should do.

> > > 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
>
> Thanks, I will stick to C.

Right, and I'm likewise happy to have left it mostly behind. It's
happily invincible (for the time being)
in its strongest domains of device drivers and kernels, but has no
business being used for any application
code. There are approximately three people on the planet who are
meticulous enough to use it for application
code, and even those people write said applications in C++.

I'm always happy to exchange anecdotes, preferences, and fireside
stories. I would like to point out, though, that having tried (and not
just tried,
I had to succeed, with whatever amounts of pain inflicted on me) to
use both of these languages to solve
the same problems in anger, I have much more than just preference
anecdotes to report. :P

> (This is also strictly inferior than the C version because the
> information about how the size of the arrays relate has been lost.)

That's a separate problem. The C version's information of how the
sizes relate is a vague suggestion
that something might do the run-time check that verifies them to
relate in the way suggested, but that
run-time check doesn't actually exist. So adding that check is that
separate problem, and when it's
added, the information comes "back" for C++ as well.