The relaxation proposed for C array copy semantics
is a simplification that makes for a more regular type.
Mostly it removes restrictions in the standards wording;
previously ill-formed code becomes well-formed.
This is generally a safe approach.

The idea, IMO, is not to encourage use of C array per se
(in application code, say, as an alternative to array classes).
Regularity enables more powerful and compatible array-
processing libraries, at a low level, across languages.

Improving C array also improves array structs and classes.
Copyability solves the member-array initialization conundrum.
Array-return aids vectorization, in BLAS helper functions say.

Further proposals would further bolster safety and utility.
A superset-then-subset approach allows safe transition.
P1997 can be the first logical step in "array renovation".

For instance, a builtin 'span' type, inspired by C++ std::span,
can build on experience gained and offer a safer way to pass
array arguments, compared to the status quo (a 'span' is
effectively Ritchies 'fat-pointer', or a reference version of it).

As part of an extended C API & ABI, a builtin span has cross-
language compatibility - better than the best span in C++
https://brevzin.github.io/c++/2018/12/03/span-best-span/

'Span' is a step towards deprecating array formal parameters
c.f. https://digitalmars.com/articles/C-biggest-mistake.html

(Walter Bright is also a strong proponent of built-in array types.
 D adds a new builtin array, alongside both C array and D's new
 multidimensional array class type.)

Concerns are understandable; C array semantics is implicated
in the reputational damage done by bad buffer-handling code.

IMO, C array is not derelict - it's a fixer upper - mostly right.
Let's fix it.

On Fri, Aug 6, 2021 at 8:04 AM Ville Voutilainen via Liaison <
liaison_at_[hidden]> wrote:
> I wonder whether WG14 has considered adding
> a new array type that would have more valuelike semantics.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n391.txt

WG14 N391/X3J11 94-076 C9X Revision Proposal
 Title: Arrays as first class objects.
 Author: Frank Farance

(WG14 helped me track down this long-lost proposal earlier this year,
 published after the NCEG Numerical C Extension Group's main run.
 I also contacted several nceg members to discuss the history.)

On Fri, 6 Aug 2021 at 14:43, Bjarne Stroustrup via Liaison
<liaison_at_[hidden]> wrote:
> worried by attempts to improve arrays - such attempts have
> in the past had a tendency to lead complexities. Good luck with all.

Don't worry - DoN't PaNiC - have a calm vacation.



On Fri, Aug 6, 2021 at 8:04 AM Ville Voutilainen via Liaison <
liaison_at_[hidden]> wrote:

> On Fri, 6 Aug 2021 at 14:43, Bjarne Stroustrup via Liaison
> <liaison_at_[hidden]> wrote:
> >
> > Apologies for not attending. I am on vacation with only phone access.
> I'm hopeful about progress on character sets, but worried by attempts to
> improve arrays - such attempts have in the past had a tendency to lead
> complexities. Good luck with all.
>
> It looks like I can't attend this meeting either, I have leisurely
> engagements earlyish in the evening my local time. I have reservations
> about the array proposal, I wonder whether WG14 has considered adding
> a new array type that would have more valuelike semantics.
> The concern about adding these abilities into the existing arrays is
> that they may still have problematic semantics (like very eager
> decay),
> and the current limitations can be an advantage, because they keep
> arrays more confined and contained, rather than suggesting that
> they're available for general use like more regular types are.
>
> In C++ we have a clear break from traditional arrays to std::array.
> That works wonderfully well for some audiences, much better
> than partially extending what traditional arrays can do. My main
> feedback item would be to seriously look at that sort of an
> alternative,
> and better explain what 'funny' semantics of arrays remain after the
> things proposed in this paper.
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/08/0663.php
>