Topic: East pointers-to-array
Author: will wray <wjwray@gmail.com>
Date: Tue, 6 Nov 2018 15:36:10 -0500
Raw View
--000000000000655d06057a04f4f0
Content-Type: text/plain; charset="UTF-8"
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>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKjnZWqJjO7kcjUt4YuvJuQM_6ZCmJHc%2Bh5zfhx8y%2Bd8nN5JcA%40mail.gmail.com.
--000000000000655d06057a04f4f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Pointer-to-array declara=
tion syntax is tricky to read and write.<div>Pointers compose left-to-right=
while extents are right-to-left.</div><div><br></div><div>It'd be easi=
er to read and write if pointers could shift from left=C2=A0to right.</div>=
<div><br></div><div>Examples:</div><div><font face=3D"monospace, monospace"=
>=C2=A0T(*)[] -> T[]*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T(*a)[];=C2=A0 -=
> T[]* a;</font></div><div><font face=3D"monospace, monospace">=C2=A0T(*=
)[M] -> T[M]*=C2=A0 =C2=A0 =C2=A0 =C2=A0 T(*a)[M]; -> T[M]* a;</font>=
</div><div><font face=3D"monospace, monospace">=C2=A0T(*)[M][N] -> T[M][=
N]*=C2=A0 T(*a)[M][N]; -> T[M][N]* a;</font></div><div><font face=3D"mon=
ospace, monospace">=C2=A0T(*[M])[N] -> T[M]*[N]=C2=A0 T(*a[M])[N]; ->=
T[M]* a[N];</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> T a[M]*[N];</fon=
t></div><div><span style=3D"font-family:monospace,monospace">=C2=A0</span><=
br></div><div>This seems similar to the case with cv qualifiers on left or=
=C2=A0right of the type.</div><div><br></div><div>Can the grammar cope with=
this or are there parsing ambiguities?</div><div>(I know this has been con=
sidered before but don't know the refs - D&E?)</div><div><br></div>=
<div>The motivation?</div><div>'East pointer' is an alternative to =
P0332's 'Relaxed Incomplete' proposal to allow</div><div>incomp=
lete bounds to appear in not just the first position of an array type decla=
ration</div><div>P0332=C2=A0is at a deadend without advocacy as there is co=
ncern about side-effects</div><div><a href=3D"https://kokkos.github.io/arra=
y_ref/proposals/P0332.html">https://kokkos.github.io/array_ref/proposals/P0=
332.html</a><br></div><div><br></div><div><font face=3D"monospace, monospac=
e">T[4][][2][1]</font><span style=3D"color:rgb(36,41,46);font-family:-apple=
-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,=
"Apple Color Emoji","Segoe UI Emoji","Segoe UI Sym=
bol";font-size:14px">=C2=A0uses incomplete bound=C2=A0</span><font fac=
e=3D"monospace, monospace">[]</font>=C2=A0<span style=3D"color:rgb(36,41,46=
);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helveti=
ca,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji"=
;,"Segoe UI Symbol";font-size:14px">to represent a dynamic extent=
-</span></div><div><font color=3D"#24292e" face=3D"monospace, monospace"><=
span style=3D"font-size:14px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</sp=
an></font><span style=3D"color:rgb(36,41,46);font-family:-apple-system,Blin=
kMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple =
Color Emoji","Segoe UI Emoji","Segoe UI Symbol";fo=
nt-size:14px">it requires a change to the type system and language rules.</=
span></div><div><font face=3D"monospace, monospace">T[4]*[2][1]=C2=A0</font=
><span style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSyste=
mFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emo=
ji","Segoe UI Emoji","Segoe UI Symbol";font-size:1=
4px">=C2=A0uses pointer </span><span style=3D"color:rgb(36,41,46);font-size=
:14px"><font face=3D"monospace, monospace">*</font></span><span style=3D"co=
lor:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe =
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Seg=
oe UI Emoji","Segoe UI Symbol";font-size:14px">=C2=A0</span>=
<span style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystem=
Font,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoj=
i","Segoe UI Emoji","Segoe UI Symbol";font-size:14=
px">to represent a dynamic extent, requiring</span></div><div><span style=
=3D"color:rgb(36,41,46);font-family:monospace,monospace;font-size:14px">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><font color=3D"#24292e"><span =
style=3D"font-size:14px"><font face=3D"-apple-system, BlinkMacSystemFont, S=
egoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, S=
egoe UI Symbol">no change to the type system, only declaration syntax.</fon=
t></span></font><span style=3D"color:rgb(36,41,46);font-family:-apple-syste=
m,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"=
Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol&qu=
ot;;font-size:14px"><br></span></div><div><span style=3D"color:rgb(36,41,46=
);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helveti=
ca,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji"=
;,"Segoe UI Symbol";font-size:14px"><br></span></div><div><font f=
ace=3D"monospace, monospace">F</font>or now the type can be used with exist=
ing syntax=C2=A0<font color=3D"#24292e" face=3D"-apple-system, BlinkMacSyst=
emFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI=
Emoji, Segoe UI Symbol"><span style=3D"font-size:14px">T</span></font><fon=
t face=3D"monospace, monospace">(*[4])[2][1]</font></div><div>or a type ali=
as with=C2=A0<font face=3D"monospace, monospace">0</font>=C2=A0representing=
dynamic extent:=C2=A0<font face=3D"monospace, monospace">mdarray_t<T,4,=
0,2,1></font>=C2=A0</div><div><br></div><div><br></div><div><br></div><d=
iv><br></div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKjnZWqJjO7kcjUt4YuvJuQM_6ZCmJHc%2Bh=
5zfhx8y%2Bd8nN5JcA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKjnZWqJjO7k=
cjUt4YuvJuQM_6ZCmJHc%2Bh5zfhx8y%2Bd8nN5JcA%40mail.gmail.com</a>.<br />
--000000000000655d06057a04f4f0--
.
Author: gmisocpp@gmail.com
Date: Tue, 6 Nov 2018 14:31:45 -0800 (PST)
Raw View
------=_Part_2712_1789211285.1541543505479
Content-Type: multipart/alternative;
boundary="----=_Part_2713_1189855909.1541543505479"
------=_Part_2713_1189855909.1541543505479
Content-Type: text/plain; charset="UTF-8"
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?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53e34e8f-4ab6-4ce1-8b4e-0adda9f7cf39%40isocpp.org.
------=_Part_2713_1189855909.1541543505479
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>If agreement=C2=A0is reached to=C2=A0change syntax he=
re, might=C2=A0this also be a good time to suggest this:</div><div><div><fo=
nt face=3D"monospace, monospace">=C2=A0T(*)[M][N] -> T[M][N]*=C2=A0 beco=
mes T(*a)[M,N] -> T[M,N]* a;</font></div></div><div><br></div><div>i.e. =
Let multiple-dimensions be specified as a comma separated list?</div><div>E=
specially=C2=A0if there=C2=A0is a desire to do away with overloading the co=
mma operator?<br></div>
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53e34e8f-4ab6-4ce1-8b4e-0adda9f7cf39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/53e34e8f-4ab6-4ce1-8b4e-0adda9f7cf39=
%40isocpp.org</a>.<br />
------=_Part_2713_1189855909.1541543505479--
------=_Part_2712_1789211285.1541543505479--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 6 Nov 2018 17:44:27 -0500
Raw View
--00000000000029e2d7057a06bffa
Content-Type: text/plain; charset="UTF-8"
On Tue, Nov 6, 2018 at 5:31 PM <gmisocpp@gmail.com> wrote:
> 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;
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZTvURxg02HabTTWtxUO1RSrACBJbHr%3D%2BCV1Rta2zWyog%40mail.gmail.com.
--00000000000029e2d7057a06bffa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Nov 6,=
2018 at 5:31 PM <<a href=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.c=
om</a>> wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>Especially=C2=A0if there=C2=A0is a desire to do away with overloading the =
comma operator?</div></div></blockquote><div><br>There are components that =
make heavy use of overloaded comma,<br>I doubt that doing away with it will=
happen.<br><br>For example, there are things like<br><font face=3D"monospa=
ce, monospace">=C2=A0 =C2=A0 Matrix<int, 2, 3> m;<br>=C2=A0 =C2=A0 m =
=3D 1, 2, 3,</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 4, 5, 6;<br></font></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZTvURxg02HabTTWtxUO1RSrACBJbHr=
%3D%2BCV1Rta2zWyog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZTvURx=
g02HabTTWtxUO1RSrACBJbHr%3D%2BCV1Rta2zWyog%40mail.gmail.com</a>.<br />
--00000000000029e2d7057a06bffa--
.
Author: will wray <wjwray@gmail.com>
Date: Tue, 6 Nov 2018 15:37:12 -0800 (PST)
Raw View
------=_Part_2736_1110976739.1541547432713
Content-Type: multipart/alternative;
boundary="----=_Part_2737_497765927.1541547432713"
------=_Part_2737_497765927.1541547432713
Content-Type: text/plain; charset="UTF-8"
On Tuesday, November 6, 2018 at 5:44:41 PM UTC-5, Hyman Rosen wrote:
>
> 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.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d6d154ce-f33a-4580-8fbb-943c4c39625f%40isocpp.org.
------=_Part_2737_497765927.1541547432713
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 6, 2018 at 5:44:41 PM UTC-5, Hyman Ro=
sen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v class=3D"gmail_quote"><div>For example, there are things like<br><font fa=
ce=3D"monospace, monospace">=C2=A0 =C2=A0 Matrix<int, 2, 3> m;<br>=C2=
=A0 =C2=A0 m =3D 1, 2, 3,</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 =C2=A0 =C2=A0 4, 5, 6;<br></font></div></div></div></bloc=
kquote><div><br></div><div>(Looks like the init is missing braces until, do=
h, overloaded comma!)</div><div><br></div><div>Reminds me that I didn't=
give a reference to the mdspan proposal <a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2018/p0009r8.html">P0009</a></div><div>which wa=
s the motivation for the array-type notation to specify extents.</div><div>=
<br></div><div>The mdspan for a 'view' of the above Matrix type wou=
ld have been (<span style=3D"font-family: arial, sans-serif;">assuming P033=
2)</span>:</div><div><br></div><div><div><span style=3D"font-family: monosp=
ace, monospace;">=C2=A0 =C2=A0 mdspan<int[3][2]> m_view(m);</span><br=
style=3D"font-family: monospace, monospace;"></div></div><div><div><span s=
tyle=3D"font-family: monospace, monospace;">=C2=A0 =C2=A0 mdspan<int[][2=
]> m_view(m);=C2=A0 // first extent dynamic</span><br style=3D"font-fami=
ly: monospace, monospace;"></div></div><div><span style=3D"font-family: mon=
ospace, monospace;"><br></span></div><div>This suggested 'East-pointer&=
#39; notation maintains the 'natural' array notation<font face=3D"a=
rial, sans-serif"><br></font></div><div>(with intermediate dynamic extents =
represented by pointer '*' like a 'wildcard').</div><div><b=
r></div><div><font face=3D"arial, sans-serif">With P0332 derailed, the prop=
osed syntax mdspan is currently:</font></div><div><font face=3D"arial, sans=
-serif"><br></font></div><div><span style=3D"font-family: monospace, monosp=
ace;">=C2=A0 =C2=A0 mdspan<int,</span>extents<3,2>> m_view(m);<=
br></div><div><span style=3D"font-family: monospace, monospace;">=C2=A0 =C2=
=A0 mdspan<int,</span>extents<dynamic_extent,2>> m_view(m);<br>=
</div><div><br></div><div>I prefer the original notation.</div><div><br></d=
iv></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d6d154ce-f33a-4580-8fbb-943c4c39625f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d6d154ce-f33a-4580-8fbb-943c4c39625f=
%40isocpp.org</a>.<br />
------=_Part_2737_497765927.1541547432713--
------=_Part_2736_1110976739.1541547432713--
.
Author: will wray <wjwray@gmail.com>
Date: Tue, 6 Nov 2018 16:28:03 -0800 (PST)
Raw View
------=_Part_10_2072069966.1541550483566
Content-Type: multipart/alternative;
boundary="----=_Part_11_1447677357.1541550483566"
------=_Part_11_1447677357.1541550483566
Content-Type: text/plain; charset="UTF-8"
On Tuesday, November 6, 2018 at 5:31:45 PM UTC-5, gmis...@gmail.com wrote:
>
> 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?
>
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.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06d7df97-aa1d-41f5-a4db-c513abdb76d6%40isocpp.org.
------=_Part_11_1447677357.1541550483566
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 6, 2018 at 5:31:45 PM UTC-5, gmis...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>If agreement=C2=A0is reached to=C2=A0change syntax here, might=C2=
=A0this also be a good time to suggest this:</div><div><div><font face=3D"m=
onospace, monospace">=C2=A0T(*)[M][N] -> T[M][N]*=C2=A0 becomes T(*a)[M,=
N] -> T[M,N]* a;</font></div></div><div><br></div><div>i.e. Let multiple=
-dimensions be specified as a comma separated list?</div><div>Especially=C2=
=A0if there=C2=A0is a desire to do away with overloading the comma operator=
?<br></div></div></blockquote><div><br></div><div>For reference, here's=
a link:</div><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/201=
8/p1161r0.html">P1161R0</a> "Deprecate uses of the comma operator in s=
ubscripting expressions"<div>This paper is also aimed at improving arr=
ay interfaces like P0009 mdspan.</div><div>Deprecation of comma operators i=
n this context is a necessary first step.</div><div>It is only proposed for=
indexing / subscripting (as far as I have noticed).</div><div><br></div><d=
iv>There are a couple of pros for commas in the declaration syntax:</div><d=
iv>Commas would allow for variadic expansion of the extents.</div><div>For =
symmetry with subscripting, as 'declaration follows use'.</div><div=
><br></div><div>And more cons</div><div>C++20 allows most index juggling to=
be done as one-liners</div><div>(so variadic expansion is less motivating =
going forward).</div><div>Introduces a C-incompatible syntax choice with li=
ttle motivation.</div><div>See what heat the 'east const' vs 'c=
onst west' talk causes</div><div>(with little light generated).</div><d=
iv><br></div><div>BTW. I noticed an error in my original post (well, at lea=
st one...).</div><div>(Guess this proves the point that the current syntax =
is confusing).</div><div>I'll post the erratum tomorrow, unless it is s=
potted earlier.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/06d7df97-aa1d-41f5-a4db-c513abdb76d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/06d7df97-aa1d-41f5-a4db-c513abdb76d6=
%40isocpp.org</a>.<br />
------=_Part_11_1447677357.1541550483566--
------=_Part_10_2072069966.1541550483566--
.
Author: will wray <wjwray@gmail.com>
Date: Thu, 8 Nov 2018 14:27:51 -0800 (PST)
Raw View
------=_Part_706_1290073013.1541716071279
Content-Type: multipart/alternative;
boundary="----=_Part_707_105558189.1541716071280"
------=_Part_707_105558189.1541716071280
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, November 6, 2018 at 3:36:24 PM UTC-5, will wray wrote:
>
> 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=
=20
considered introducing postfix =E2=80=9Cpointer to=E2=80=9D operator -> as =
an alternative=20
to the prefix *:
Design & Evolution section 2.8.1 The C Declaration Syntax
(This section=20
<https://play.google.com/books/reader?id=3DhS9mDwAAQBAJ&hl=3Den&pg=3DGBS.PT=
63.w.1.0.80.0.2> is=20
currently available as sample content in the Google Play edition)
int v[10]->; // array of pointers to intsint p->[10]; // pointer to array o=
f 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=20
int*[10].
However, in array context, it is better written as an incomplete bound,=20
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=20
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=20
syntax would (temporarily at least) add complexity to a known mess. Also,=
=20
even though the old style is a boon to teachers of trivia and to people who=
=20
want to ridicule C, it is not a significant problem for C programmers. In=
=20
this case, I=E2=80=99m not sure if I did the right thing, though.=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0029a8aa-ef1b-4aa3-bdde-119677c8454e%40isocpp.or=
g.
------=_Part_707_105558189.1541716071280
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 6, 2018 at 3:36:24 PM UTC-5, will wra=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div =
dir=3D"ltr"><div dir=3D"ltr"><div>Can the grammar cope with this or are the=
re parsing ambiguities?</div><div>(I know this has been considered before b=
ut don't know the refs - D&E?)</div></div></div></div></blockquote>=
<div><br></div><p style=3D"box-sizing: border-box; margin-bottom: 16px; col=
or: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "=
Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji"=
, "Segoe UI Emoji", "Segoe UI Symbol"; font-size: 14px;=
">Indeed, Bjarne did discuss this 'postfix pointer' declaration syn=
tax in D&E:</p><blockquote style=3D"box-sizing: border-box; margin: 0px=
0px 16px; border-left: 0.25em solid rgb(223, 226, 229); color: rgb(106, 11=
5, 125); padding: 0px 1em; font-family: -apple-system, BlinkMacSystemFont, =
"Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji=
", "Segoe UI Emoji", "Segoe UI Symbol"; font-size:=
14px;"><p style=3D"box-sizing: border-box;">Together with Doug McIlroy, An=
drew Koenig, Jonathan Shopiro, and others I considered introducing postfix =
=E2=80=9Cpointer to=E2=80=9D operator -> as an alternative to the prefix=
*:</p></blockquote><p style=3D"box-sizing: border-box; margin-bottom: 16px=
; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &=
quot;Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji&=
quot;, "Segoe UI Emoji", "Segoe UI Symbol"; font-size: =
14px;"><span style=3D"box-sizing: border-box; font-weight: 600;">Design &am=
p; Evolution</span>=C2=A0section 2.8.1 The C Declaration Syntax<br style=3D=
"box-sizing: border-box;">(This=C2=A0<a href=3D"https://play.google.com/boo=
ks/reader?id=3DhS9mDwAAQBAJ&hl=3Den&pg=3DGBS.PT63.w.1.0.80.0.2" rel=
=3D"nofollow" style=3D"box-sizing: border-box; background-color: initial; c=
olor: rgb(3, 102, 214);">section</a>=C2=A0is currently available as sample =
content in the Google Play edition)</p><div class=3D"highlight highlight-so=
urce-c++" style=3D"box-sizing: border-box; margin-bottom: 16px; color: rgb(=
36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI=
", Helvetica, Arial, sans-serif, "Apple Color Emoji", "=
Segoe UI Emoji", "Segoe UI Symbol"; font-size: 14px; overflo=
w: visible !important;"><pre style=3D"box-sizing: border-box; font-family: =
SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, mono=
space; font-size: 11.9px; overflow-wrap: normal; background-color: rgb(246,=
248, 250); border-radius: 3px; line-height: 1.45; overflow: auto; padding:=
16px; word-break: normal;"><span class=3D"pl-k" style=3D"box-sizing: borde=
r-box; color: rgb(215, 58, 73);">int</span> v[<span class=3D"pl-c1" style=
=3D"box-sizing: border-box; color: rgb(0, 92, 197);">10</span>]->; <span=
class=3D"pl-c" style=3D"box-sizing: border-box; color: rgb(106, 115, 125);=
"><span class=3D"pl-c" style=3D"box-sizing: border-box;">//</span> array of=
pointers to ints</span>
<span class=3D"pl-k" style=3D"box-sizing: border-box; color: rgb(215, 58, 7=
3);">int</span> p->[<span class=3D"pl-c1" style=3D"box-sizing: border-bo=
x; color: rgb(0, 92, 197);">10</span>]; <span class=3D"pl-c" style=3D"box-s=
izing: border-box; color: rgb(106, 115, 125);"><span class=3D"pl-c" style=
=3D"box-sizing: border-box;">//</span> pointer to array of ints</span></pre=
></div><p style=3D"box-sizing: border-box; margin-bottom: 16px; color: rgb(=
36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI=
", Helvetica, Arial, sans-serif, "Apple Color Emoji", "=
Segoe UI Emoji", "Segoe UI Symbol"; font-size: 14px;">The re=
ason for using=C2=A0<code style=3D"box-sizing: border-box; font-family: SFM=
ono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospa=
ce; font-size: 11.9px; background-color: rgba(27, 31, 35, 0.05); border-rad=
ius: 3px; padding: 0.2em 0.4em;">-></code>=C2=A0rather than=C2=A0<code s=
tyle=3D"box-sizing: border-box; font-family: SFMono-Regular, Consolas, &quo=
t;Liberation Mono", Menlo, Courier, monospace; font-size: 11.9px; back=
ground-color: rgba(27, 31, 35, 0.05); border-radius: 3px; padding: 0.2em 0.=
4em;">*</code>=C2=A0is not explained.<br style=3D"box-sizing: border-box;">=
The types themselves would be=C2=A0<code style=3D"box-sizing: border-box; f=
ont-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, C=
ourier, monospace; font-size: 11.9px; background-color: rgba(27, 31, 35, 0.=
05); border-radius: 3px; padding: 0.2em 0.4em;">int[10]-></code>=C2=A0an=
d=C2=A0<code style=3D"box-sizing: border-box; font-family: SFMono-Regular, =
Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size=
: 11.9px; background-color: rgba(27, 31, 35, 0.05); border-radius: 3px; pad=
ding: 0.2em 0.4em;">int->[10]</code>.<br style=3D"box-sizing: border-box=
;">There is ambiguity with=C2=A0<code style=3D"box-sizing: border-box; font=
-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Cour=
ier, monospace; font-size: 11.9px; background-color: rgba(27, 31, 35, 0.05)=
; border-radius: 3px; padding: 0.2em 0.4em;">*</code>=C2=A0in the 'firs=
t position' so=C2=A0<code style=3D"box-sizing: border-box; font-family:=
SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, mon=
ospace; font-size: 11.9px; background-color: rgba(27, 31, 35, 0.05); border=
-radius: 3px; padding: 0.2em 0.4em;">int->[10]</code>=C2=A0is not=C2=A0<=
code style=3D"box-sizing: border-box; font-family: SFMono-Regular, Consolas=
, "Liberation Mono", Menlo, Courier, monospace; font-size: 11.9px=
; background-color: rgba(27, 31, 35, 0.05); border-radius: 3px; padding: 0.=
2em 0.4em;">int*[10]</code>.<br style=3D"box-sizing: border-box;">However, =
in array context, it is better written as an incomplete bound,=C2=A0<code s=
tyle=3D"box-sizing: border-box; font-family: SFMono-Regular, Consolas, &quo=
t;Liberation Mono", Menlo, Courier, monospace; font-size: 11.9px; back=
ground-color: rgba(27, 31, 35, 0.05); border-radius: 3px; padding: 0.2em 0.=
4em;">int[][10]</code>.<br style=3D"box-sizing: border-box;">Beyond the fir=
st position is there ambiguity? If there is I don't see it.<br style=3D=
"box-sizing: border-box;">If not then we can use=C2=A0<code style=3D"box-si=
zing: border-box; font-family: SFMono-Regular, Consolas, "Liberation M=
ono", Menlo, Courier, monospace; font-size: 11.9px; background-color: =
rgba(27, 31, 35, 0.05); border-radius: 3px; padding: 0.2em 0.4em;">*</code>=
=C2=A0in postfix except in first position where=C2=A0<code style=3D"box-siz=
ing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mo=
no", Menlo, Courier, monospace; font-size: 11.9px; background-color: r=
gba(27, 31, 35, 0.05); border-radius: 3px; padding: 0.2em 0.4em;">[]</code>=
=C2=A0is needed.</p><div class=3D"highlight highlight-source-c++" style=3D"=
box-sizing: border-box; margin-bottom: 16px; color: rgb(36, 41, 46); font-f=
amily: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, =
Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji"=
;, "Segoe UI Symbol"; font-size: 14px; overflow: visible !importa=
nt;"><pre style=3D"box-sizing: border-box; font-family: SFMono-Regular, Con=
solas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1=
1.9px; overflow-wrap: normal; background-color: rgb(246, 248, 250); border-=
radius: 3px; line-height: 1.45; overflow: auto; padding: 16px; word-break: =
normal;"><span class=3D"pl-k" style=3D"box-sizing: border-box; color: rgb(2=
15, 58, 73);">int</span> v[<span class=3D"pl-c1" style=3D"box-sizing: borde=
r-box; color: rgb(0, 92, 197);">10</span>]*; <span class=3D"pl-c" style=3D"=
box-sizing: border-box; color: rgb(106, 115, 125);"><span class=3D"pl-c" st=
yle=3D"box-sizing: border-box;">//</span> array of pointers to ints</span>
<span class=3D"pl-k" style=3D"box-sizing: border-box; color: rgb(215, 58, 7=
3);">int</span> p[][<span class=3D"pl-c1" style=3D"box-sizing: border-box; =
color: rgb(0, 92, 197);">10</span>]; <span class=3D"pl-c" style=3D"box-sizi=
ng: border-box; color: rgb(106, 115, 125);"><span class=3D"pl-c" style=3D"b=
ox-sizing: border-box;">//</span> pointer to array of 10 ints</span></pre><=
/div><ul style=3D"box-sizing: border-box; margin-bottom: 16px; margin-top: =
0px; padding-left: 2em; color: rgb(36, 41, 46); font-family: -apple-system,=
BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, &q=
uot;Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Sym=
bol"; font-size: 14px;"><li style=3D"box-sizing: border-box; margin-le=
ft: 0px;">After first position bounds and pointers can be arbitrarily mixed=
</li><li style=3D"box-sizing: border-box; margin-top: 0.25em; margin-left: =
0px;">The 'wildcard'=C2=A0<code style=3D"box-sizing: border-box; fo=
nt-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Co=
urier, monospace; font-size: 11.9px; background-color: rgba(27, 31, 35, 0.0=
5); border-radius: 3px; padding: 0.2em 0.4em;">*</code>'s can represent=
'dynamic extents'.</li></ul><div><span style=3D"color: rgb(106, 11=
5, 125); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI&quo=
t;, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Sego=
e UI Emoji", "Segoe UI Symbol"; font-size: 14px;">My eventua=
l 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 ridicu=
le C, it is not a significant problem for C programmers. In this case,</spa=
n><span style=3D"color: rgb(106, 115, 125); font-family: -apple-system, Bli=
nkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "=
Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol&=
quot;; font-size: 14px;">=C2=A0</span><span style=3D"color: rgb(106, 115, 1=
25); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", =
Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI=
Emoji", "Segoe UI Symbol"; font-size: 14px; box-sizing: bor=
der-box; font-weight: 600;">I=E2=80=99m not sure if I did the right thing</=
span><span style=3D"color: rgb(106, 115, 125); font-family: -apple-system, =
BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, &qu=
ot;Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symb=
ol"; font-size: 14px;">, though.</span>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0029a8aa-ef1b-4aa3-bdde-119677c8454e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0029a8aa-ef1b-4aa3-bdde-119677c8454e=
%40isocpp.org</a>.<br />
------=_Part_707_105558189.1541716071280--
------=_Part_706_1290073013.1541716071279--
.
Author: will wray <wjwray@gmail.com>
Date: Thu, 8 Nov 2018 15:55:36 -0800 (PST)
Raw View
------=_Part_798_1698568370.1541721336579
Content-Type: multipart/alternative;
boundary="----=_Part_799_1980717647.1541721336580"
------=_Part_799_1980717647.1541721336580
Content-Type: text/plain; charset="UTF-8"
On Tuesday, November 6, 2018 at 3:36:24 PM UTC-5, will wray wrote:
>
> 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];
>
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 ?
> ------------------------------
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
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d9927889-37f6-4ff2-a0b6-8856a59f48a5%40isocpp.org.
------=_Part_799_1980717647.1541721336580
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 6, 2018 at 3:36:24 PM UTC-5, will wra=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div =
dir=3D"ltr"><div dir=3D"ltr"><div>Examples:</div><div><font face=3D"monospa=
ce, monospace">=C2=A0T(*)[] -> T[]*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T(=
*a)[];=C2=A0 -> T[]* a;</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0T(*)[M] -> T[M]*=C2=A0 =C2=A0 =C2=A0 =C2=A0 T(*a)[M]; -> T=
[M]* a;</font></div><div><font face=3D"monospace, monospace">=C2=A0T(*)[M][=
N] -> T[M][N]*=C2=A0 T(*a)[M][N]; -> T[M][N]* a;</font></div><div><fo=
nt face=3D"monospace, monospace">=C2=A0T(*[M])[N] -> T[M]*[N]=C2=A0 T(*a=
[M])[N]; -> T[M]* a[N];</font></div><div><font face=3D"monospace, monosp=
ace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> T a[M]=
*[N];</font></div></div></div></div></blockquote><div><br></div><div>Erratu=
m(s)</div><div>The table in the original post is completely wrong; sorry to=
anyone who puzzled over it.</div><div>(Can I edit the post or mark it as w=
rong? There's delete but don't want to remove the OP.)</div><div><b=
r></div><div>Here's a more complete corrected version:</div><div><br></=
div><div><div><span style=3D"font-family: monospace, monospace;"><b>Type pr=
efix->postfix</b>=C2=A0 =C2=A0 =C2=A0 =C2=A0<b>Object declaration prefix=
->postfix</b></span></div><div><hr></div><span style=3D"font-family: mon=
ospace, monospace;">=C2=A0T*[]=C2=A0 -> T[]*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 (Not an object type)</span></div><div><hr><p><span style=3D"f=
ont-family: monospace, monospace;">=C2=A0T*[N] -> T[N]*=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 T* a[N];=C2=A0 =C2=A0 =C2=A0-> T a[N]*;</span><=
br></p><p><span style=3D"font-family: monospace, monospace;">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( -> T[N]* a; ) ? possible=
variation ?</span></p><hr><span style=3D"font-family: monospace, monospace=
;">=C2=A0T(*)[N]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0T (*a)[N];=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 No postfix notation</span></div><div><font face=3D"monospace, monos=
pace">=C2=A0T[][N]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 T a[][N];=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0[] equivalent as param</font><br><hr><span style=3D"font-f=
amily: monospace, monospace;"></span><div><span style=3D"font-family: monos=
pace, monospace;">=C2=A0T*[M][N]=C2=A0 -> T[M][N]*=C2=A0 =C2=A0 =C2=A0T*=
a[M][N];=C2=A0 -> T a[M][N]*;</span><span style=3D"font-family: monospa=
ce, monospace;"></span></div><div><span style=3D"font-family: monospace, mo=
nospace;"><br></span></div><hr><span style=3D"font-family: monospace, monos=
pace;">=C2=A0T(*[M])[N]-> T[M]*[N]=C2=A0 =C2=A0 =C2=A0T (*a[M])[N]; ->=
; T a[M]*[N];</span><span style=3D"font-family: monospace, monospace;"></sp=
an></div><div><span style=3D"font-family: monospace, monospace;">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0( -> T[N]* a[M]; =
)?</span><span style=3D"font-family: monospace, monospace;">=C2=A0</span><s=
pan style=3D"font-family: monospace, monospace;">possible variation ?</span=
><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><div =
dir=3D"ltr"></div></div></div></blockquote></div><div><hr><span style=3D"fo=
nt-family: monospace, monospace;"></span><div><span style=3D"font-family: m=
onospace, monospace;">=C2=A0T(*)[M][N]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 T (*a)[M][N];</span><span style=3D"font-family: monosp=
ace, monospace;">=C2=A0</span><span style=3D"font-family: monospace, monosp=
ace;">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No postfix not=
ation</span></div><div><span style=3D"font-family: monospace, monospace;">=
=C2=A0T[][M][N]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0T a[][M][N];=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0</span><span style=3D"font-family: monospace, monospace;">[] equivalent =
as param</span><br></div><hr><br><span style=3D"font-family: monospace, mon=
ospace;"></span></div><div>Apologies again for any confusion. Does this=C2=
=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d9927889-37f6-4ff2-a0b6-8856a59f48a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d9927889-37f6-4ff2-a0b6-8856a59f48a5=
%40isocpp.org</a>.<br />
------=_Part_799_1980717647.1541721336580--
------=_Part_798_1698568370.1541721336579--
.
Author: will wray <wjwray@gmail.com>
Date: Thu, 8 Nov 2018 16:12:04 -0800 (PST)
Raw View
------=_Part_771_424935306.1541722324078
Content-Type: multipart/alternative;
boundary="----=_Part_772_1401701907.1541722324078"
------=_Part_772_1401701907.1541722324078
Content-Type: text/plain; charset="UTF-8"
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])
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0448db1e-893e-4dac-b6e8-a46167205a74%40isocpp.org.
------=_Part_772_1401701907.1541722324078
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The table in the original post is completely wrong. Apolog=
ies to anyone who puzzled over it.<div>I'll post a more complete correc=
ted version soon.</div><div><br></div><div>Also, in the previous post with =
D&E excerpts I got this wrong:</div><div><pre style=3D"padding: 16px; c=
olor: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, "Liberat=
ion Mono", Menlo, Courier, monospace; font-size: 11.9px; background-co=
lor: rgb(246, 248, 250); border-radius: 3px; line-height: 1.45; overflow: a=
uto; word-break: normal;"><span style=3D"color: rgb(215, 58, 73);">int</spa=
n> p[][<span style=3D"color: rgb(0, 92, 197);">10</span>]; <span style=3D"c=
olor: rgb(106, 115, 125);">// pointer to array of 10 ints</span></pre></div=
><div><br></div><div>(as you can't create an object of incomplete type =
<font face=3D"courier new, monospace">int[][10]</font>)</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0448db1e-893e-4dac-b6e8-a46167205a74%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0448db1e-893e-4dac-b6e8-a46167205a74=
%40isocpp.org</a>.<br />
------=_Part_772_1401701907.1541722324078--
------=_Part_771_424935306.1541722324078--
.