On Tue, 27 Apr 2021 at 08:47, Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
> > It does make things simpler. We can relegate legacy arrays to very
> > contained portions
> > of our code, and use the more regular facilities elsewhere. Sure, we
> > need an array
> > for the implementation guts for std::vector and std::array, and std::span covers
> > the rest. But we don't need to pass or return legacy arrays, or
> > otherwise manipulate
> > them, pretty much *anywhere*. So whether they're regular or whether
> > they fit in with
> > the rest becomes irrelevant.
>
> Then we should probably agree that C and C++ will
> evolve in different directions and not stop trying
> to maintain a common subset anymore.
>
> Because if C++ now starts claiming syntax for new C++
> arrays while sidelining C arrays to a legacy feature, then
> this obviously can't work.

I fail to see how that's obvious. C++ has been sidelining C arrays to a legacy
feature since the inception of std::vector.

As far as the alternative suggestions for what a[x, y, z] should
mean.. they very much look
like they're entertaining having it mean that a transformation-view is
generated. P0009, for instance,
already has that ability, and it's very different from that; the way
to apply a transformation
view on top of another is to just construct a different mdspan from an
mdspan. So it's done
via a converting constructor, which C plain doesn't have. So C needs
to consider whether to
make it a baked-in language facility for built-in arrays, whereas in
C++, it's just another converting
constructor of a library type.

I suppose you're right in the sense that this is not the first time
such friction is occurred. C has to provide
almost all of these things as language mechanisms, because the
language itself doesn't provide sufficient
facilities to write such things as library facilities. C++ does. That
is a fairly fundamental difference in
what can be done and how, and what the limiting factor is. C++ has
(including its library), for quite some time, been designed
in a way where the 'shackles' of the expressive power (or lack
thereof) of C are not considered binding.
There's no shortage of people who consider that one of the major
reasons why C++ is successful; it's compatible
to a nice extent, but not compatible to the point of being constrained
by the design choices of C.

And that's not news, or shouldn't be.