[std-proposals] East pointers-to-array

[will wray]

Pointer-to-array declaration syntax is tricky to read and write.
Pointers compose left-to-right while extents are right-to-left.

It'd be easier to read and write if pointers could shift from left to right.

Examples:
T(*)[] -> T[]* T(*a)[]; -> T[]* a;
T(*)[M] -> T[M]* T(*a)[M]; -> T[M]* a;
T(*)[M][N] -> T[M][N]* T(*a)[M][N]; -> T[M][N]* a;
T(*[M])[N] -> T[M]*[N] T(*a[M])[N]; -> T[M]* a[N];
-> T a[M]*[N];

This seems similar to the case with cv qualifiers on left or right of the
type.

Can the grammar cope with this or are there parsing ambiguities?
(I know this has been considered before but don't know the refs - D&E?)

The motivation?
'East pointer' is an alternative to P0332's 'Relaxed Incomplete' proposal
to allow
incomplete bounds to appear in not just the first position of an array type
declaration
P0332 is at a deadend without advocacy as there is concern about
side-effects
https://kokkos.github.io/array_ref/proposals/P0332.html

T[4][][2][1] uses incomplete bound [] to represent a dynamic extent -
it requires a change to the type system and language rules.
T[4]*[2][1] uses pointer * to represent a dynamic extent, requiring
no change to the type system, only declaration syntax.

For now the type can be used with existing syntax T(*[4])[2][1]
or a type alias with 0 representing dynamic extent: mdarray_t<T,4,0,2,1>

[g***@gmail.com]

If agreement is reached to change syntax here, might this also be a good
time to suggest this:
T(*)[M][N] -> T[M][N]* becomes T(*a)[M,N] -> T[M,N]* a;

i.e. Let multiple-dimensions be specified as a comma separated list?
Especially if there is a desire to do away with overloading the comma
operator?

[Hyman Rosen]

Post by g***@gmail.com
Especially if there is a desire to do away with overloading the comma
operator?

There are components that make heavy use of overloaded comma,
I doubt that doing away with it will happen.

For example, there are things like
Matrix<int, 2, 3> m;
m = 1, 2, 3,
4, 5, 6;

[will wray]

Post by Hyman Rosen
For example, there are things like
Matrix<int, 2, 3> m;
m = 1, 2, 3,
4, 5, 6;

(Looks like the init is missing braces until, doh, overloaded comma!)

Reminds me that I didn't give a reference to the mdspan proposal P0009
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0009r8.html>
which was the motivation for the array-type notation to specify extents.

The mdspan for a 'view' of the above Matrix type would have been (assuming
P0332):

mdspan<int[3][2]> m_view(m);
mdspan<int[][2]> m_view(m); // first extent dynamic

This suggested 'East-pointer' notation maintains the 'natural' array
notation
(with intermediate dynamic extents represented by pointer '*' like a
'wildcard').

With P0332 derailed, the proposed syntax mdspan is currently:

mdspan<int,extents<3,2>> m_view(m);
mdspan<int,extents<dynamic_extent,2>> m_view(m);

I prefer the original notation.

[will wray]

Post by g***@gmail.com
If agreement is reached to change syntax here, might this also be a good
T(*)[M][N] -> T[M][N]* becomes T(*a)[M,N] -> T[M,N]* a;
i.e. Let multiple-dimensions be specified as a comma separated list?
Especially if there is a desire to do away with overloading the comma
operator?

For reference, here's a link:
P1161R0 <http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1161r0.html>
"Deprecate uses of the comma operator in subscripting expressions"
This paper is also aimed at improving array interfaces like P0009 mdspan.
Deprecation of comma operators in this context is a necessary first step.
It is only proposed for indexing / subscripting (as far as I have noticed).

There are a couple of pros for commas in the declaration syntax:
Commas would allow for variadic expansion of the extents.
For symmetry with subscripting, as 'declaration follows use'.

And more cons
C++20 allows most index juggling to be done as one-liners
(so variadic expansion is less motivating going forward).
Introduces a C-incompatible syntax choice with little motivation.
See what heat the 'east const' vs 'const west' talk causes
(with little light generated).

BTW. I noticed an error in my original post (well, at least one...).
(Guess this proves the point that the current syntax is confusing).
I'll post the erratum tomorrow, unless it is spotted earlier.

[will wray]

Post by will wray
Can the grammar cope with this or are there parsing ambiguities?
(I know this has been considered before but don't know the refs - D&E?)

Indeed, Bjarne did discuss this 'postfix pointer' declaration syntax in D&E:

Together with Doug McIlroy, Andrew Koenig, Jonathan Shopiro, and others I
considered introducing postfix “pointer to” operator -> as an alternative
to the prefix *:

Design & Evolution section 2.8.1 The C Declaration Syntax
(This section
<https://play.google.com/books/reader?id=hS9mDwAAQBAJ&hl=en&pg=GBS.PT63.w.1.0.80.0.2> is
currently available as sample content in the Google Play edition)

int v[10]->; // array of pointers to intsint p->[10]; // pointer to array of ints

The reason for using -> rather than * is not explained.
The types themselves would be int[10]-> and int->[10].
There is ambiguity with * in the 'first position' so int->[10] is not
int*[10].
However, in array context, it is better written as an incomplete bound,
int[][10].
Beyond the first position is there ambiguity? If there is I don't see it.
If not then we can use * in postfix except in first position where [] is
needed.

int v[10]*; // array of pointers to intsint p[][10]; // pointer to array of 10 ints


- After first position bounds and pointers can be arbitrarily mixed
- The 'wildcard' *'s can represent 'dynamic extents'.

My eventual rationale for leaving things as they were was that any new
syntax would (temporarily at least) add complexity to a known mess. Also,
even though the old style is a boon to teachers of trivia and to people who
want to ridicule C, it is not a significant problem for C programmers. In
this case, I’m not sure if I did the right thing, though.

[will wray]

Post by will wray
T(*)[] -> T[]* T(*a)[]; -> T[]* a;
T(*)[M] -> T[M]* T(*a)[M]; -> T[M]* a;
T(*)[M][N] -> T[M][N]* T(*a)[M][N]; -> T[M][N]* a;
T(*[M])[N] -> T[M]*[N] T(*a[M])[N]; -> T[M]* a[N];
-> T a[M]*[N];

Erratum(s)
The table in the original post is completely wrong; sorry to anyone who
puzzled over it.
(Can I edit the post or mark it as wrong? There's delete but don't want to
remove the OP.)

Here's a more complete corrected version:

*Type prefix->postfix* *Object declaration prefix->postfix*
------------------------------
T*[] -> T[]* (Not an object type)
------------------------------

T*[N] -> T[N]* T* a[N]; -> T a[N]*;

( -> T[N]* a; ) ? possible variation ?
------------------------------
T(*)[N] T (*a)[N]; No postfix notation
T[][N] T a[][N]; [] equivalent as
param
------------------------------
T*[M][N] -> T[M][N]* T* a[M][N]; -> T a[M][N]*;

------------------------------
T(*[M])[N]-> T[M]*[N] T (*a[M])[N]; -> T a[M]*[N];
( -> T[N]* a[M]; )? possible
variation ?

Post by will wray
------------------------------

T(*)[M][N] T (*a)[M][N]; No postfix notation
T[][M][N] T a[][M][N]; [] equivalent as
param
------------------------------

Apologies again for any confusion. Does this

[will wray]

The table in the original post is completely wrong. Apologies to anyone who
puzzled over it.
I'll post a more complete corrected version soon.

Also, in the previous post with D&E excerpts I got this wrong:

int p[][10]; // pointer to array of 10 ints


(as you can't create an object of incomplete type int[][10])