[Bug c++/103238] New: c++ Feature: array-copy experimental extensions implementing P1997

[Bug c++/103238] New: c++ Feature: array-copy experimental extensions implementing P1997

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238

            Bug ID: 103238
           Summary: c++ Feature: array-copy experimental extensions
                    implementing P1997
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: patch
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wjwray at gmail dot com
  Target Milestone: ---

This is a feature-tracking PR for an incoming patch to implement
C++ proposal P1997 "Relaxing restrictions on array", that adds:

  C array copy semantics:
    * array-array initializations
    * array-array assignments
    * array return-by-value from functions
     (array formal parameters are unchanged; there's no pass-by-value).

  Plus, C++ specific:
    * array pseudo-destructors
    * array element type deduction
     (i.e. admitting placeholder auto in array variable declarations).

Implementation strategy

The features are implemented as an experimental extension, disabled by default.
The patch should have no effect until enabled by the new option:

    -farray-copy (flag_array_copy)

This single flag enables all features, copy-semantic or not.
The features are enabled as an extension in all -std modes as appropriate
(i.e. placeholder auto in C++11 and up).

The extension is documented as experimental with no guarantee of stability;
features may be added, removed or changed in detail.
In particular, there's no guarantee of ABI stability; 
allowing array as a function return type has ABI impact:

  * Calling conventions for the array return slot must be agreed
  * On the C++ side, name-mangling conventions must be defined.

The plan is to first merge array-copy as experimental, with ABI defined as
'what the code does', and then to go ahead with ABI discussions, decide on
a written specification, and then do any required implementation work.

C and C++ proposal status

P1997R1 was seen by SG22, the ISO Joint C and C++ Liaison Study Group,
on Aug 6th 2021 with positive feedback from both C and C++ sides of the room.

It was voted forward to C++ EWG, with the strong recommendation to proceed
only once implementation experience has been gained. This work is the result.
The EWG chair prefers that "it be reviewed and tentatively approved by ...gcc
code owners" as an upstreamable contribution. The aim is to merge array-copy
extensions on trunk for wide availability. Likewise for other compilers.

The C compatible subset of the copy-semantic changes apply to C language,
and could be made to accommodate array extensions such as VLAs and VM types.
The plan is to follow up on the C side once this patch is accepted into g++:
(1) to assist in writing the C proposal based on this experience, and
(2) to contribute to the gcc implementation, with support of C code owners.

The C++ proposal will be revised based on experience and feedback as the
implementation is honed via issues, bug fixes or further opportunities.

An interesting suggestion is that these array extensions be incorporated into
C and C++ standards as a DR, applying as they do to the C subset and all -std,
with DR standing for Dennis Ritchie, great language designer in the sky.

[Bug c++/103238] c++ Feature: array-copy experimental extensions implementing P1997

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sun, 14 Nov 2021, wjwray at gmail dot com via Gcc-bugs wrote:

> An interesting suggestion is that these array extensions be incorporated into
> C and C++ standards as a DR, applying as they do to the C subset and all -std,
> with DR standing for Dennis Ritchie, great language designer in the sky.

This is a good example of what I said in today's WG14 meeting about C++ 
going overboard about applying changes to previous standard versions.  
Something should only be considered a DR for previous standard versions if 
what was in the previous standard version is unambiguously *wrong* - not 
simply if a new feature seems nice to have or more convenient to use.

[Bug c++/103238] c++ Feature: array-copy experimental extensions implementing P1997

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238

--- Comment #2 from Will Wray <wjwray at gmail dot com> ---
(It was my own 'interesting suggestion' to myself; going stir crazy coding!)
(Apologies if I stirred anything other than thought.)

Thank you for emphasising the important point on DRs. It's true that some
C++ DRs change behaviour, and lack clear communication of rationale. 

The strategy to merge this as a compiler extension seems the best way forward.
The g++ patch is ready for review with the P1997 feature mostly implemented or
marked as TODO. Test coverage is decent but there'll be omissions and errors.
The -farray-copy flag isolates the main code paths from the extension paths.

And, I hope I don't take DMR in vain; his design for 'the C object model',
with array as foundation, was inspired, if flawed - a rough cut gem.

[Bug c++/103238] c++ Feature: array-copy experimental extensions implementing P1997

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
There is no reason to think this would be a DR for C++.

[Bug c++/103238] c++ Feature: array-copy experimental extensions implementing P1997

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238

--- Comment #4 from Will Wray <wjwray at gmail dot com> ---
First cut implementation in two patches, submitted for review:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585105.html