------=_Part_684_1386244335.1550503853824
Content-Type: multipart/alternative;
 boundary="----=_Part_685_1570025427.1550503853825"

------=_Part_685_1570025427.1550503853825
Content-Type: text/plain; charset="UTF-8"

With C++17's value-category simplification, array value return from
functions could now be allowed.

Has this been discussed before here or elsewhere? Links?

With array return allowed, struct wrappers like std::array are not
necessary:

  char abc1D()[3] { return {'a','b','c'}; } // array return with brace-init

Ties in nicely with structured bindings for simple packing & unpacking of
multiple same-type returns:

  auto [a,b,c] = abc1D();  // structured binding to elements of returned
array

The structured binding provides the lifetime extension (and can provide
implicit array copy too).
Otherwise, remember to bind the returned array to a reference:

  auto& abc = abc1D();

The danger, of course, is that attempts to copy fail because of array decay
to pointer
which applies all too eagerly on assignments:

  auto dangle = abc();     // dangle is a char* to an array that just
expired
  char abc_bcpy[3]{abc()}; // error: invalid conversion from 'char*' to
'char'
  char abc_pcpy[3](abc()); // with P0960, paren-init for aggregate, same as
above

--
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/e1c07ac6-73d0-40c8-98a0-60a5c8a6c575%40isocpp.org.

------=_Part_685_1570025427.1550503853825
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>With C++17&#39;s value-category simplification, array=
 value return from functions could now be allowed.<br></div><div><br></div>=
<div>Has this been discussed before here or elsewhere? Links?</div><div><br=
></div><div>With array return allowed, struct wrappers like std::array are =
not necessary:</div><div><br></div><div class=3D"prettyprint" style=3D"bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overf=
low-wrap: break-word;"><code class=3D"prettyprint" style=3D""><div class=3D=
"subprettyprint" style=3D""><span style=3D"color: #000;" class=3D"styled-by=
-prettify">=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">char</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> abc1D</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&=
#39;a&#39;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&#39;b&#3=
9;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">&#39;c&#39;</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// array return with brace-init</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><div><br></div><div>Ties in nicely with structured bindings for simple pa=
cking &amp; unpacking of multiple same-type returns:</div><div><br></div><d=
iv><div class=3D"prettyprint" style=3D"border-width: 1px; border-style: sol=
id; border-color: rgb(187, 187, 187); background-color: rgb(250, 250, 250);=
 overflow-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">c</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> abc1D</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> =C2=A0</span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// structured binding to elements of =
returned array</span></div></code></div><div><br></div></div><div>The struc=
tured binding provides the lifetime extension (and can provide implicit arr=
ay copy too).</div><div>Otherwise, remember to bind the returned array to a=
 reference:</div><div><br></div><div><div class=3D"prettyprint" style=3D"bo=
rder-width: 1px; border-style: solid; border-color: rgb(187, 187, 187); bac=
kground-color: rgb(250, 250, 250); overflow-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">=C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> abc </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> abc1D</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
();</span></div></code></div></div><div><br></div><div>The danger, of cours=
e, is that attempts to copy fail because of array decay to pointer</div><di=
v>which applies all too eagerly on assignments:</div><div><br></div><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> dangle </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> abc</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> =C2=A0 =C2=A0 </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// dangle is a char* to an array that jus=
t expired</span></div></code></div><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; overflow-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">=C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">char</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> abc_bcpy</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">abc</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">()};</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// error: invalid conversion fr=
om &#39;char*&#39; to &#39;char&#39;</span></div></code></div><div><div cla=
ss=3D"prettyprint" style=3D"border-width: 1px; border-style: solid; border-=
color: rgb(187, 187, 187); background-color: rgb(250, 250, 250); overflow-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> abc_pcpy</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">](</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">abc</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">());</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// with P0960, paren-init for aggregate, same as above</span></div></code=
></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/e1c07ac6-73d0-40c8-98a0-60a5c8a6c575%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e1c07ac6-73d0-40c8-98a0-60a5c8a6c575=
%40isocpp.org</a>.<br />

------=_Part_685_1570025427.1550503853825--

------=_Part_684_1386244335.1550503853824--

.

--000000000000f09b1605822d11c0
Content-Type: text/plain; charset="UTF-8"

Am Mo., 18. Feb. 2019 um 16:30 Uhr schrieb will wray <wjwray@gmail.com>:

> [...]
>
> With array return allowed, struct wrappers like std::array are not
> necessary:
>

What's wrong with std::array as a function return type? Both returning with
brace-init and structured bindings work for std::array.

--
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/CAM76qmtaaQtCP_%2Bf5Z6B3jCsruZVzSR7Q6ezcVX%3DzMSjq4ujcQ%40mail.gmail.com.

--000000000000f09b1605822d11c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">Am Mo., 18. Feb. 2019 um 16:30=C2=A0Uhr s=
chrieb will wray &lt;<a href=3D"mailto:wjwray@gmail.com">wjwray@gmail.com</=
a>&gt;:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>[...]</div><div><br></div><div>With array return allowed, str=
uct wrappers like std::array are not necessary:</div></div></blockquote><di=
v>=C2=A0</div><div>What&#39;s wrong with std::array as a function return ty=
pe? Both returning with brace-init and structured bindings work for std::ar=
ray.</div><div>=C2=A0</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAM76qmtaaQtCP_%2Bf5Z6B3jCsruZVzSR7Q6=
ezcVX%3DzMSjq4ujcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmtaaQtC=
P_%2Bf5Z6B3jCsruZVzSR7Q6ezcVX%3DzMSjq4ujcQ%40mail.gmail.com</a>.<br />

--000000000000f09b1605822d11c0--

.

------=_Part_693_1766519651.1550507077021
Content-Type: multipart/alternative;
 boundary="----=_Part_694_347649933.1550507077022"

------=_Part_694_347649933.1550507077022
Content-Type: text/plain; charset="UTF-8"

std::array is long in the tooth as an early C++11 demo class.

std::array hasn't proved itself as a 'vocabulary' type for API usage -
spans and ranges supersede and they operate fine with built-in array.

std::array does not 'roundtrip' the wrapped array type; data() returns a
pointer.
std::array tuple-access customization for structured binding access trumps
the regular
aggregate structured binding access which would have given direct
'roundtrip' access...
std::array is awkward to use for multidimensional arrays.
std::array CTAD guides added for 17 only give 'all or none' deduction - you
can't provide
just the type and deduce size - function's deducing built-in array are more
flexible.

std::array doesn't have C-linkage.
std::array may add end-padding (?).

Built-in array, despite the danger, is a simple language-level solution.
Built-in array has std::swap specialization...

On Monday, February 18, 2019 at 10:49:31 AM UTC-5, Manuel Bergler wrote:
>
>
> Am Mo., 18. Feb. 2019 um 16:30 Uhr schrieb will wray <wjw...@gmail.com
> <javascript:>>:
>
>> [...]
>>
>> With array return allowed, struct wrappers like std::array are not
>> necessary:
>>
>
> What's wrong with std::array as a function return type? Both returning
> with brace-init and structured bindings work for std::array.
>
>

--
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/8a165c32-718a-4247-93b4-44235a2cf122%40isocpp.org.

------=_Part_694_347649933.1550507077022
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>std::array is long in the tooth as an early C++11 dem=
o class.</div><div><br></div><div>std::array hasn&#39;t proved itself as a =
&#39;vocabulary&#39; type for API usage -</div><div>spans and ranges supers=
ede and they operate fine with built-in array.</div><div><br></div><div>std=
::array does not &#39;roundtrip&#39; the wrapped array type; data() returns=
 a pointer.<br></div><div>std::array tuple-access customization for structu=
red binding access trumps the regular</div><div>aggregate structured bindin=
g access which would have given direct &#39;roundtrip&#39; access...</div><=
div>std::array is awkward to use for multidimensional arrays.<br></div><div=
><div>std::array CTAD guides added for 17 only give &#39;all or none&#39; d=
eduction - you can&#39;t provide<br></div><div><div>just the type and deduc=
e size - function&#39;s deducing built-in array are more flexible.</div></d=
iv><div><br></div><div><div>std::array doesn&#39;t have C-linkage.<br></div=
><div>std::array may add end-padding (?).</div><div></div></div><div><br></=
div><div>Built-in array, despite the danger, is a simple language-level sol=
ution.</div><div>Built-in array has std::swap specialization...=C2=A0</div>=
<div><br>On Monday, February 18, 2019 at 10:49:31 AM UTC-5, Manuel Bergler =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div di=
r=3D"ltr"></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Am Mo., 18.=
 Feb. 2019 um 16:30=C2=A0Uhr schrieb will wray &lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"uATE48hQAAAJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">wjw...@gmail.com</a>&gt;:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>[...]</div><div><br></div><div>With array return allowed, struct wrapper=
s like std::array are not necessary:</div></div></blockquote><div>=C2=A0</d=
iv><div>What&#39;s wrong with std::array as a function return type? Both re=
turning with brace-init and structured bindings work for std::array.</div><=
div>=C2=A0<br></div></div></div>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/8a165c32-718a-4247-93b4-44235a2cf122%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8a165c32-718a-4247-93b4-44235a2cf122=
%40isocpp.org</a>.<br />

------=_Part_694_347649933.1550507077022--

------=_Part_693_1766519651.1550507077021--

.

On 18/02/2019 17:24, will wray wrote:
> std::array is long in the tooth as an early C++11 demo class.

Wrong - it's perfectly simple for entry level. Source, I teach C++ since
10 years and array has never been a problem
C array always have been.


> std::array hasn't proved itself as a 'vocabulary' type for API usage -
> spans and ranges supersede and they operate fine with built-in array.

std:::array is a data owner, nothing comparable to span

> std::array does not 'roundtrip' the wrapped array type; data() returns
> a pointer.

And ?

> std::array is awkward to use for multidimensional arrays.

Opinion, not fact

> std::array CTAD guides added for 17 only give 'all or none' deduction
> - you can't provide
> just the type and deduce size - function's deducing built-in array are
> more flexible.
Make a proposal and amend them.

builtin array are non copiable, are not object etc...
Is the game of give opinions instead of facts done or ?

C style arrays must disappear as they have no value over std::array

--
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/f870e6c5-4cb2-47f8-d963-363e68626841%40gmail.com.

.

------=_Part_908_1554217323.1550591560645
Content-Type: multipart/alternative;
 boundary="----=_Part_909_1718410094.1550591560645"

------=_Part_909_1718410094.1550591560645
Content-Type: text/plain; charset="UTF-8"

(Trying one more time - previous attempts went to the google groups spam
filter)

C-array is an atomic aggregate - a pure crystal condensate of one atom type.

This thread is to discuss improved language support for C-array via array
return.

(It is not about addressing std::array shortcomings.
 It is not an either / or.
 C-array and std::array are different tools for different tasks.)

> The fact that array return is now technically feasible shows how far C++
language
specification has risen above its C roots.
What was impossible for forty years is now possible.

> Raw array is analogous to raw pointer.
We've outgrown the urge to wrap all pointers - that's not so smart.
Raw pointers have been rehabilitated as the right tool for low level code.
Raw arrays deserve to be rehabilitated, with a little language level love.

On Monday, February 18, 2019 at 11:33:19 AM UTC-5, Joel Falcou wrote:
>
> C style arrays must disappear as they have no value over std::array
>

(Eh? Trollish joke?)
C-array is essential to implement std::array - it can't and won't disappear.

std::array is a molecular aggregate, an abstract compound

> 'compound': make (something bad) worse; intensify the negative aspects of.


On Monday, February 18, 2019 at 11:33:19 AM UTC-5, Joel Falcou wrote:
>
>
> On 18/02/2019 17:24, will wray wrote:
> > std::array is long in the tooth as an early C++11 demo class.
>
> Wrong - it's perfectly simple for entry level. Source, I teach C++ since
> 10 years and array has never been a problem
> C array always have been.
>
>
> > std::array hasn't proved itself as a 'vocabulary' type for API usage -
> > spans and ranges supersede and they operate fine with built-in array.
>
> std:::array is a data owner, nothing comparable to span
>
> > std::array does not 'roundtrip' the wrapped array type; data() returns
> > a pointer.
>
> And ?
>
> > std::array is awkward to use for multidimensional arrays.
>
> Opinion, not fact
>
> > std::array CTAD guides added for 17 only give 'all or none' deduction
> > - you can't provide
> > just the type and deduce size - function's deducing built-in array are
> > more flexible.
> Make a proposal and amend them.
>
> builtin array are non copiable, are not object etc...
> Is the game of give opinions instead of facts done or ?
>
> C style arrays must disappear as they have no value over std::array
>
>

--
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/65d69c2c-3fa1-40a5-8120-53bfd345ac90%40isocpp.org.

------=_Part_909_1718410094.1550591560645
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(Trying one more time - previous attempts went to the goog=
le groups spam filter)<br><div><br><span style=3D"font-family: Roboto, &quo=
t;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size: small;">C-=
array is an atomic aggregate - a pure crystal condensate of one atom type.<=
/span><div><font face=3D"Roboto, Helvetica Neue, Helvetica, Arial, sans-ser=
if" size=3D"2"><br></font><div><div><div><span style=3D"font-family: Roboto=
, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size: smal=
l;">This thread is to discuss improved language support for C-array via arr=
ay return.</span></div><div><span style=3D"font-family: Roboto, &quot;Helve=
tica Neue&quot;, Helvetica, Arial, sans-serif; font-size: small;"><br></spa=
n></div><div><span style=3D"font-family: Roboto, &quot;Helvetica Neue&quot;=
, Helvetica, Arial, sans-serif; font-size: small;">(It is not about address=
ing std::array shortcomings.</span></div><div><span style=3D"font-family: R=
oboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size:=
 small;">=C2=A0It is not an either / or.=C2=A0</span></div><div>=C2=A0C-arr=
ay and std::array are different tools for different tasks.)</div><div><div =
style=3D"font-family: Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial,=
 sans-serif; font-size: small;"><blockquote class=3D"gmail_quote" style=3D"=
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;"></blockquote></blockquote>The=
 fact that array return is now technically feasible shows how far C++ langu=
age<br>specification has risen above its C roots.</div><div style=3D"font-f=
amily: Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; fo=
nt-size: small;">What was impossible for forty years is now possible.</div>=
<div style=3D"font-family: Roboto, &quot;Helvetica Neue&quot;, Helvetica, A=
rial, sans-serif; font-size: small;"><blockquote class=3D"gmail_quote" styl=
e=3D"border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
 1px solid rgb(204, 204, 204); padding-left: 1ex;"></blockquote></blockquot=
e>Raw array is analogous to raw pointer.<br>We&#39;ve outgrown the urge to =
wrap all pointers - that&#39;s not so smart.<br>Raw pointers have been reha=
bilitated as the right tool for low level code.<br>Raw arrays deserve to be=
 rehabilitated, with a little language level love.</div><br style=3D"font-f=
amily: Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; fo=
nt-size: small;"><span style=3D"font-family: Roboto, &quot;Helvetica Neue&q=
uot;, Helvetica, Arial, sans-serif; font-size: small;">On Monday, February =
18, 2019 at 11:33:19 AM UTC-5, Joel Falcou wrote:</span><blockquote class=
=3D"gmail_quote" style=3D"font-family: Roboto, &quot;Helvetica Neue&quot;, =
Helvetica, Arial, sans-serif; font-size: small; margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">C style arra=
ys must disappear as they have no value over std::array=C2=A0<br></blockquo=
te><div style=3D"font-family: Roboto, &quot;Helvetica Neue&quot;, Helvetica=
, Arial, sans-serif; font-size: small;"><br></div><div style=3D"font-family=
: Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-si=
ze: small;">(Eh? Trollish joke?)</div><div style=3D"font-family: Roboto, &q=
uot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size: small;">=
C-array is essential to implement std::array - it can&#39;t and won&#39;t d=
isappear.</div><div style=3D"font-family: Roboto, &quot;Helvetica Neue&quot=
;, Helvetica, Arial, sans-serif; font-size: small;"><br></div><div style=3D=
"font-family: Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-se=
rif; font-size: small;">std::array is a molecular aggregate, an abstract co=
mpound<div><blockquote class=3D"gmail_quote" style=3D"font-family: Arial, H=
elvetica, sans-serif; font-size: 13px; margin: 0px 0px 0px 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span style=3D"font-f=
amily: Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; fo=
nt-size: small;">&#39;compound&#39;:=C2=A0</span><span style=3D"font-family=
: arial, sans-serif; font-size: small;">make (something bad) worse; intensi=
fy the negative aspects of.</span></blockquote><div style=3D"font-family: A=
rial, Helvetica, sans-serif; font-size: 13px;"><span style=3D"font-family: =
Roboto, &quot;Helvetica Neue&quot;, Helvetica, Arial, sans-serif; font-size=
: small;"><br></span></div></div></div>On Monday, February 18, 2019 at 11:3=
3:19 AM UTC-5, Joel Falcou wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">
<br>On 18/02/2019 17:24, will wray wrote:
<br>&gt; std::array is long in the tooth as an early C++11 demo class.
<br>
<br>Wrong - it&#39;s perfectly simple for entry level. Source, I teach C++ =
since=20
<br>10 years and array has never been a problem
<br>C array always have been.
<br>
<br>
<br>&gt; std::array hasn&#39;t proved itself as a &#39;vocabulary&#39; type=
 for API usage -
<br>&gt; spans and ranges supersede and they operate fine with built-in arr=
ay.
<br>
<br>std:::array is a data owner, nothing comparable to span
<br>
<br>&gt; std::array does not &#39;roundtrip&#39; the wrapped array type; da=
ta() returns=20
<br>&gt; a pointer.
<br>
<br>And ?
<br>
<br>&gt; std::array is awkward to use for multidimensional arrays.
<br>
<br>Opinion, not fact
<br>
<br>&gt; std::array CTAD guides added for 17 only give &#39;all or none&#39=
; deduction=20
<br>&gt; - you can&#39;t provide
<br>&gt; just the type and deduce size - function&#39;s deducing built-in a=
rray are=20
<br>&gt; more flexible.
<br>Make a proposal and amend them.
<br>
<br>builtin array are non copiable, are not object etc...
<br>Is the game of give opinions instead of facts done or ?
<br>
<br>C style arrays must disappear as they have no value over std::array
<br>
<br></blockquote></div></div></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&quot; 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/65d69c2c-3fa1-40a5-8120-53bfd345ac90%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/65d69c2c-3fa1-40a5-8120-53bfd345ac90=
%40isocpp.org</a>.<br />

------=_Part_909_1718410094.1550591560645--

------=_Part_908_1554217323.1550591560645--

.

--0000000000004e8728058241c312
Content-Type: text/plain; charset="UTF-8"

On Tue, 19 Feb 2019, 15:52 will wray <wjwray@gmail.com wrote:

> (Trying one more time - previous attempts went to the google groups spam
> filter)
>
> C-array is an atomic aggregate - a pure crystal condensate of one atom
> type.
>
> This thread is to discuss improved language support for C-array via array
> return.
>
> (It is not about addressing std::array shortcomings.
>  It is not an either / or.
>  C-array and std::array are different tools for different tasks.)
>
>> The fact that array return is now technically feasible shows how far C++
> language
> specification has risen above its C roots.
> What was impossible for forty years is now possible.
>
>> Raw array is analogous to raw pointer.
> We've outgrown the urge to wrap all pointers - that's not so smart.
> Raw pointers have been rehabilitated as the right tool for low level code.
> Raw arrays deserve to be rehabilitated, with a little language level love.
>

I'm not so sure on that. std::array gives the compiler the knowledge of the
size so that the user doesn't have to pass it around manually, but in a
compiled executable I don't see any difference except for removal of jump
instructions in the std::array case thanks to loop unrolling.

Im definitely against any notion of removing raw arrays from the language
(because it is nonsensical), but I also never use them explicitly unless
I'm doing unmentionable casty and c-stringy things in low latency settings
- and even then I'm doing it via std::array.data().


> On Monday, February 18, 2019 at 11:33:19 AM UTC-5, Joel Falcou wrote:
>>
>> C style arrays must disappear as they have no value over std::array
>>
>
> (Eh? Trollish joke?)
> C-array is essential to implement std::array - it can't and won't
> disappear.
>
> std::array is a molecular aggregate, an abstract compound
>
>> 'compound': make (something bad) worse; intensify the negative aspects
>> of.
>
>

--
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/CAC%2B0CCPKvKDGrYdvLwPGtKYQ-2%3DmOFdi5tAA0PzwU_JAvQHjtQ%40mail.gmail.com.

--0000000000004e8728058241c312
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
19 Feb 2019, 15:52 will wray &lt;<a href=3D"mailto:wjwray@gmail.com">wjwray=
@gmail.com</a> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">(Trying one more time - previous attempts went to the google groups spa=
m filter)<br><div><br><span style=3D"font-family:Roboto,&quot;Helvetica Neu=
e&quot;,Helvetica,Arial,sans-serif;font-size:small">C-array is an atomic ag=
gregate - a pure crystal condensate of one atom type.</span><div><font face=
=3D"Roboto, Helvetica Neue, Helvetica, Arial, sans-serif" size=3D"2"><br></=
font><div><div><div><span style=3D"font-family:Roboto,&quot;Helvetica Neue&=
quot;,Helvetica,Arial,sans-serif;font-size:small">This thread is to discuss=
 improved language support for C-array via array return.</span></div><div><=
span style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial=
,sans-serif;font-size:small"><br></span></div><div><span style=3D"font-fami=
ly:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:s=
mall">(It is not about addressing std::array shortcomings.</span></div><div=
><span style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Ari=
al,sans-serif;font-size:small">=C2=A0It is not an either / or.=C2=A0</span>=
</div><div>=C2=A0C-array and std::array are different tools for different t=
asks.)</div><div><div style=3D"font-family:Roboto,&quot;Helvetica Neue&quot=
;,Helvetica,Arial,sans-serif;font-size:small"><blockquote class=3D"gmail_qu=
ote" style=3D"border-left:1px solid rgb(204,204,204);padding-left:1ex"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></blockquote>The=
 fact that array return is now technically feasible shows how far C++ langu=
age<br>specification has risen above its C roots.</div><div style=3D"font-f=
amily:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-siz=
e:small">What was impossible for forty years is now possible.</div><div sty=
le=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-se=
rif;font-size:small"><blockquote class=3D"gmail_quote" style=3D"border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"></blockquote></blockquote>Raw array is analogous to ra=
w pointer.<br>We&#39;ve outgrown the urge to wrap all pointers - that&#39;s=
 not so smart.<br>Raw pointers have been rehabilitated as the right tool fo=
r low level code.<br>Raw arrays deserve to be rehabilitated, with a little =
language level love.</div></div></div></div></div></div></div></blockquote>=
</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m not so su=
re on that. std::array gives the compiler the knowledge of the size so that=
 the user doesn&#39;t have to pass it around manually, but in a compiled ex=
ecutable I don&#39;t see any difference except for removal of jump instruct=
ions in the std::array case thanks to loop unrolling.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Im definitely against any notion of removing =
raw arrays from the language (because it is nonsensical), but I also never =
use them explicitly unless I&#39;m doing unmentionable casty and c-stringy =
things in low latency settings - and even then I&#39;m doing it via std::ar=
ray.data().</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
<div><div><div><br style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,H=
elvetica,Arial,sans-serif;font-size:small"><span style=3D"font-family:Robot=
o,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:small">On=
 Monday, February 18, 2019 at 11:33:19 AM UTC-5, Joel Falcou wrote:</span><=
blockquote class=3D"gmail_quote" style=3D"font-family:Roboto,&quot;Helvetic=
a Neue&quot;,Helvetica,Arial,sans-serif;font-size:small;margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">C style arra=
ys must disappear as they have no value over std::array=C2=A0<br></blockquo=
te><div style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Ar=
ial,sans-serif;font-size:small"><br></div><div style=3D"font-family:Roboto,=
&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:small">(Eh?=
 Trollish joke?)</div><div style=3D"font-family:Roboto,&quot;Helvetica Neue=
&quot;,Helvetica,Arial,sans-serif;font-size:small">C-array is essential to =
implement std::array - it can&#39;t and won&#39;t disappear.</div><div styl=
e=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-ser=
if;font-size:small"><br></div><div style=3D"font-family:Roboto,&quot;Helvet=
ica Neue&quot;,Helvetica,Arial,sans-serif;font-size:small">std::array is a =
molecular aggregate, an abstract compound<div><blockquote class=3D"gmail_qu=
ote" style=3D"font-family:Arial,Helvetica,sans-serif;font-size:13px;margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<span style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Aria=
l,sans-serif;font-size:small">&#39;compound&#39;:=C2=A0</span><span style=
=3D"font-family:arial,sans-serif;font-size:small">make (something bad) wors=
e; intensify the negative aspects of.</span></blockquote></div></div></div>=
</div></div></div></div></div>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAC%2B0CCPKvKDGrYdvLwPGtKYQ-2%3DmOFdi=
5tAA0PzwU_JAvQHjtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPKvK=
DGrYdvLwPGtKYQ-2%3DmOFdi5tAA0PzwU_JAvQHjtQ%40mail.gmail.com</a>.<br />

--0000000000004e8728058241c312--

.

On Tuesday, 19 February 2019 07:52:40 PST will wray wrote:
> > The fact that array return is now technically feasible shows how far C++
>
> language
> specification has risen above its C roots.
> What was impossible for forty years is now possible.

C++ will not diverge from C here, since that would be a behaviour difference.
Currently returning arrays is a compiler error in both languages, so it's
possible for C++ to define the behaviour, but only if C decides forever to use
the same behaviour or keep it a compilation error.

Conclusion: you must convince WG14 first, or get their word that they will not
define this behaviour.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products



--
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/2410729.WPaXvBSSja%40tjmaciei-mobl1.

.

------=_Part_1481_260753636.1550634919821
Content-Type: multipart/alternative;
 boundary="----=_Part_1482_1978518224.1550634919822"

------=_Part_1482_1978518224.1550634919822
Content-Type: text/plain; charset="UTF-8"

On Tuesday, February 19, 2019 at 10:52:40 AM UTC-5, will wray wrote:
>
> (Trying one more time - previous attempts went to the google groups spam
> filter)
>
> C-array is an atomic aggregate - a pure crystal condensate of one atom
> type.
>
> This thread is to discuss improved language support for C-array via array
> return.
>
> (It is not about addressing std::array shortcomings.
>  It is not an either / or.
>  C-array and std::array are different tools for different tasks.)
>

The general argument against your proposal is that they should not be
viewed that way. That `std::array` ought to be viewed as fixed version of
C-arrays, and we should endeavor to make `std::array` more palatable in
places where it is problematic, rather than trying to make C-arrays more
functional.

It's a conflict of world-views. You see C-arrays as an inherent good that
should be brought up to parity with other language features. Others see
C-arrays as a necessary evil which should be marginalized as much as
possible by providing alternatives (`std::array`, `std::span`, etc) that
work more naturally with C++'s rules.

From a more objective POV, my feeling is that `std::array` really only has
two significant flaws relative to to C arrays: not being able to omit the
size of an array while still specifying the type (which is a matter of
CTAD), and the general verbosity of multi-dimensional arrays. The fact that
`data()` returns a pointer is irrelevant in a world where `std::span` can
be used for taking references to sized arrays. `std::array<T,N>` is
convertible to a `std::span<T, N>` or to a dynamically sized span; that's
good enough.

On a personal level, the biggest problem I have with increasing the use of
C-arrays is syntactic. Just look at one of your examples:

char abc1D()[3] { return {'a','b','c'}; }

If the `[3]` applies to the `char` as part of the return type, why is it on
the other side of the function name? The return type should be either on
the left or the right; it shouldn't be scattered between them. My first
thought was that you were somehow creating an array of functions, not a
function that returns an array.

By contrast:

std::array<char, 3> abc1D();

That looks like a regular function returning a regular type. The entirety
of the return type is in one place in the function declaration. It may be
more verbose than your version, but that regularity and consistency has its
place.

Contrast this to GLSL, where arrays can in fact be return values. In that
syntax, the array size is visually (or can be written as) part of the type.
You can write `float[30] array`, rather than `float array[30]` (though the
latter works too). So when you return an array, you do `float[10]
func_name(...)`.

GLSL of course had the advantage that pointers don't exist, so there are no
decay-to-pointer rules...

Also, there is a problem of a lack of consistency. If you can return an
array by value, and you can declare a variable that is an array which
receives that array by value... why can't you pass an array by value to a
function? Because `void func(char arr[3])` still just takes a pointer, not
an array. And you can't fix that, since it would be a breaking change. By
contrast, `void func(std::span<char, 3> arr)` is not a lie; you cannot just
pass a pointer to that.

Encouraging the use of C-arrays in the way you suggest is kind of a lie.
Right now, arrays are not regular types; they are objects, but they're not
regular types. Being able to return them by value suggests that they are
value types, but it only makes them value types in one case.

Also, I'm curious as to what it is exactly about C++17's value category
system that makes your proposal possible where it was not possible before.

--
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/7eac0e9f-4042-45d6-93b3-de89ba4ebae0%40isocpp.org.

------=_Part_1482_1978518224.1550634919822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 19, 2019 at 10:52:40 AM UTC-5, will w=
ray 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">(Tr=
ying one more time - previous attempts went to the google groups spam filte=
r)<br><div><br><span style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;=
,Helvetica,Arial,sans-serif;font-size:small">C-array is an atomic aggregate=
 - a pure crystal condensate of one atom type.</span><div><font size=3D"2" =
face=3D"Roboto, Helvetica Neue, Helvetica, Arial, sans-serif"><br></font><d=
iv><div><div><span style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,H=
elvetica,Arial,sans-serif;font-size:small">This thread is to discuss improv=
ed language support for C-array via array return.</span></div><div><span st=
yle=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-s=
erif;font-size:small"><br></span></div><div><span style=3D"font-family:Robo=
to,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:small">(=
It is not about addressing std::array shortcomings.</span></div><div><span =
style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans=
-serif;font-size:small">=C2=A0It is not an either / or.=C2=A0</span></div><=
div>=C2=A0C-array and std::array are different tools for different tasks.)<=
/div></div></div></div></div></div></blockquote><div><br></div><div>The gen=
eral argument against your proposal is that they should not be viewed that =
way. That `std::array` ought to be viewed as fixed version of C-arrays, and=
 we should endeavor to make `std::array` more palatable in places where it =
is problematic, rather than trying to make C-arrays more functional.<br><br=
>It&#39;s a conflict of world-views. You see C-arrays as an inherent good t=
hat should be brought up to parity with other language features. Others see=
 C-arrays as a necessary evil which should be marginalized as much as possi=
ble by providing alternatives (`std::array`, `std::span`, etc) that work mo=
re naturally with C++&#39;s rules.</div><div><br></div><div>From a more obj=
ective POV, my feeling is that `std::array` really only has two significant=
 flaws relative to to C arrays: not being able to omit the size of an array=
 while still specifying the type (which is a matter of CTAD), and the gener=
al verbosity of multi-dimensional arrays. The fact that `data()` returns a =
pointer is irrelevant in a world where `std::span` can be used for taking r=
eferences to sized arrays. `std::array&lt;T,N&gt;` is convertible to a `std=
::span&lt;T, N&gt;` or to a dynamically sized span; that&#39;s good enough.=
<br></div><div><br></div><div>On a personal level, the biggest problem I ha=
ve with increasing the use of C-arrays is syntactic. Just look at one of yo=
ur examples:<br><br>char abc1D()[3] { return {&#39;a&#39;,&#39;b&#39;,&#39;=
c&#39;}; }<br><br>If the `[3]` applies to the `char` as part of the return =
type, why is it on the other side of the function name? The return type sho=
uld be either on the left or the right; it shouldn&#39;t be scattered betwe=
en them. My first thought was that you were somehow creating an array of fu=
nctions, not a function that returns an array.<br><br>By contrast:<br><br>s=
td::array&lt;char, 3&gt; abc1D();<br><br>That looks like a regular function=
 returning a regular type. The entirety of the return type is in one place =
in the function declaration. It may be more verbose than your version, but =
that regularity and consistency has its place.<br><br>Contrast this to GLSL=
, where arrays can in fact be return values. In that syntax, the array size=
 is visually (or can be written as) part of the type. You can write `float[=
30] array`, rather than `float array[30]` (though the latter works too). So=
 when you return an array, you do `float[10] func_name(...)`.</div><div><br=
></div><div>GLSL of course had the advantage that pointers don&#39;t exist,=
 so there are no decay-to-pointer rules...<br></div><div><br></div><div>Als=
o, there is a problem of a lack of consistency. If you can return an array =
by value, and you can declare a variable that is an array which receives th=
at array by value... why can&#39;t you pass an array by value to a function=
? Because `void func(char arr[3])` still just takes a pointer, not an array=
.. And you can&#39;t fix that, since it would be a breaking change. By contr=
ast, `void func(std::span&lt;char, 3&gt; arr)` is not a lie; you cannot jus=
t pass a pointer to that.<br></div><div><br>Encouraging the use of C-arrays=
 in the way you suggest is kind of a lie. Right now, arrays are not regular=
 types; they are objects, but they&#39;re not regular types. Being able to =
return them by value suggests that they are value types, but it only makes =
them value types in one case.<br><br>Also, I&#39;m curious as to what it is=
 exactly about C++17&#39;s value category system that makes your proposal p=
ossible where it was not possible before.<br></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/7eac0e9f-4042-45d6-93b3-de89ba4ebae0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7eac0e9f-4042-45d6-93b3-de89ba4ebae0=
%40isocpp.org</a>.<br />

------=_Part_1482_1978518224.1550634919822--

------=_Part_1481_260753636.1550634919821--

.

------=_Part_1903_175351419.1550680141905
Content-Type: multipart/alternative;
 boundary="----=_Part_1904_744185688.1550680141906"

------=_Part_1904_744185688.1550680141906
Content-Type: text/plain; charset="UTF-8"

Thanks Nicol; an eloquent response addressing the topic.

While not quite an inherent good, C-array is our closest model of
contiguous memory,
which close mapping was surely a contributor to the success of C and then
C++.

On Tuesday, February 19, 2019 at 10:55:20 PM UTC-5, Nicol Bolas wrote:
>
> ...I'm curious as to what it is exactly about C++17's value category
> system that makes your proposal possible where it was not possible before.


I was referring to P0135 "Guaranteed copy elision through simplified value
categories".
See e.g. Barry's blog Value Categories in C++17
<https://medium.com/@barryrevzin/value-categories-in-c-17-f56ae54bccbe>;
'copy' initialization of a non-movable type
is the usual example (some say 'elison' is not the right word - 'evasion'
may be more accurate).
I guess that array return could have been possible as a special case
without this.

This proposed change allows a callee to allocate and return static
array storage in the caller,
unwrapped - array is already an aggregate, no need to conglomerate it.

Syntactically, inside-out "declaration resembles usage" is a stumbling
block,
though it is now nicely addressed with a using declaration;
template <typename T, size_t N> using carray = T[N];

Again, raw arrays, like raw pointers, are for low level code that calls for
language expertise.
Poor syntax here could be seen as a feature as it puts off those who should
not use it.

Ritchie calls out array-pointer relationship and declaration syntax as C's
main issues
in the Critque section of The Development of the C Language
<https://www.bell-labs.com/usr/dmr/www/chist.html#>,
which goes on to give several paragraphs on array:

The other characteristic feature of C, its treatment of arrays, is more
> suspect on practical grounds, though it also has real virtues.
> ...
> C's treatment of arrays in general (not just strings) has unfortunate
> implications both for optimization and for future extensions. The
> prevalence of pointers in C programs, whether those declared explicitly or
> arising from arrays, means that optimizers must be cautious, and must use
> careful dataflow techniques to achieve good results. Sophisticated
> compilers can understand what most pointers can possibly change, but some
> important usages remain difficult to analyze. For example, functions with
> pointer arguments derived from arrays are hard to compile into efficient
> code on vector machines, because it is seldom possible to determine that
> one argument pointer does not overlap data also referred to by another
> argument, or accessible externally. More fundamentally, the definition of C
> so specifically describes the semantics of arrays that changes or
> extensions treating arrays as more primitive objects, and permitting
> operations on them as wholes, become hard to fit into the existing
> language. Even extensions to permit the declaration and use of
> multidimensional arrays whose size is determined dynamically are not
> entirely straightforward [MacDonald 89] [Ritchie 90], although they would
> make it much easier to write numerical libraries in C. Thus, C covers the
> most important uses of strings and arrays arising in practice by a uniform
> and simple mechanism, but leaves problems for highly efficient
> implementations and for extensions.


C++ has addressed most of these array critique points (apart from dynamic
arrays...).
Highly efficient implementation is now possible. This extension to array
return is possible.
C++'s object model addresses aliasing, so correct C++ code can be as
efficient as Fortran.
As long as decay to pointer is avoided, the program retains full
information for array object-type.
References allow passing sized arrays to functions, so 'permitting
operations on them as wholes'.

With references, passing array by value is not necessary;
it is inconsistent that you cannot pass array by value but references make
this unimportant.
Allowing a callee to allocate and return array static storage is more
important, as functions can then
wrap array creation rather than taking as an argument a mutable reference
to a pre-declared array.

C-array and std::array are different tools for different tasks.
>
>
> The general argument against your proposal is that they should not be
> viewed that way.

That `std::array` ought to be viewed as fixed version of C-arrays


I was wrong to say 'different tools'; C-array is a building block,
std::array an edifice.
Similarly, although std::array attempts to fix C-array, it has to do so by
wrapping C-array.

we should endeavor to make `std::array` more palatable in places where it
> is problematic,

rather than trying to make C-arrays more functional.


We should do both. This is C++; if we can, we do.

std::array aimed at a strong data-hiding abstraction.
More recent additions to C++, like structured binding, make data more
manifest.
Eventually, static reflection blows open all hidden data, including C-array
members.
C-array compatibility then grows in importance.

std::array 'palatability' improvement should be a new thread...
.... but, since it is raised here, let's totally raise the edifice and try
to patch it up.

Here's a way to fork std::array:

template <typename T, std::size_t... E> struct array;

template <typename T, std::size_t N> struct array<T,N>
                                     { T data[N]{}; }; // std array

template <typename T, std::size_t N> struct array<T[N]>
                                     { /* ? */ };  // improved array

Then std::array<int[4]> gives a new improved array.

This way, we could also add std::array_ref as a reference wrapper specific
to C-array -
a std compatibility wrapper for existing C-array, including
multi-dimensional.

int m44[4][4];
array_ref{m44}; // copyable, copy-assignable from array, comparable, etc.

Strange how 'two world-view' conflict burns on; I hadn't mean to spark
flame-wars of old
(weren't flame wars fought between languages, not one language burning its
foundation).

On Tuesday, February 19, 2019 at 10:55:20 PM UTC-5, Nicol Bolas wrote:
>
> On Tuesday, February 19, 2019 at 10:52:40 AM UTC-5, will wray wrote:
>>
>> (Trying one more time - previous attempts went to the google groups spam
>> filter)
>>
>> C-array is an atomic aggregate - a pure crystal condensate of one atom
>> type.
>>
>> This thread is to discuss improved language support for C-array via array
>> return.
>>
>> (It is not about addressing std::array shortcomings.
>>  It is not an either / or.
>>  C-array and std::array are different tools for different tasks.)
>>
>
> The general argument against your proposal is that they should not be
> viewed that way. That `std::array` ought to be viewed as fixed version of
> C-arrays, and we should endeavor to make `std::array` more palatable in
> places where it is problematic, rather than trying to make C-arrays more
> functional.
>
> It's a conflict of world-views. You see C-arrays as an inherent good that
> should be brought up to parity with other language features. Others see
> C-arrays as a necessary evil which should be marginalized as much as
> possible by providing alternatives (`std::array`, `std::span`, etc) that
> work more naturally with C++'s rules.
>
> From a more objective POV, my feeling is that `std::array` really only has
> two significant flaws relative to to C arrays: not being able to omit the
> size of an array while still specifying the type (which is a matter of
> CTAD), and the general verbosity of multi-dimensional arrays. The fact that
> `data()` returns a pointer is irrelevant in a world where `std::span` can
> be used for taking references to sized arrays. `std::array<T,N>` is
> convertible to a `std::span<T, N>` or to a dynamically sized span; that's
> good enough.
>
> On a personal level, the biggest problem I have with increasing the use of
> C-arrays is syntactic. Just look at one of your examples:
>
> char abc1D()[3] { return {'a','b','c'}; }
>
> If the `[3]` applies to the `char` as part of the return type, why is it
> on the other side of the function name? The return type should be either on
> the left or the right; it shouldn't be scattered between them. My first
> thought was that you were somehow creating an array of functions, not a
> function that returns an array.
>
> By contrast:
>
> std::array<char, 3> abc1D();
>
> That looks like a regular function returning a regular type. The entirety
> of the return type is in one place in the function declaration. It may be
> more verbose than your version, but that regularity and consistency has its
> place.
>
> Contrast this to GLSL, where arrays can in fact be return values. In that
> syntax, the array size is visually (or can be written as) part of the type.
> You can write `float[30] array`, rather than `float array[30]` (though the
> latter works too). So when you return an array, you do `float[10]
> func_name(...)`.
>
> GLSL of course had the advantage that pointers don't exist, so there are
> no decay-to-pointer rules...
>
> Also, there is a problem of a lack of consistency. If you can return an
> array by value, and you can declare a variable that is an array which
> receives that array by value... why can't you pass an array by value to a
> function? Because `void func(char arr[3])` still just takes a pointer, not
> an array. And you can't fix that, since it would be a breaking change. By
> contrast, `void func(std::span<char, 3> arr)` is not a lie; you cannot just
> pass a pointer to that.
>
> Encouraging the use of C-arrays in the way you suggest is kind of a lie.
> Right now, arrays are not regular types; they are objects, but they're not
> regular types. Being able to return them by value suggests that they are
> value types, but it only makes them value types in one case.
>
> Also, I'm curious as to what it is exactly about C++17's value category
> system that makes your proposal possible where it was not possible before.
>
>

--
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/2cbcb629-3c44-47f3-931a-126196f0a485%40isocpp.org.

------=_Part_1904_744185688.1550680141906
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks Nicol; an eloquent response addressing the topic.<d=
iv><br></div><div>While not quite an inherent good, C-array is our closest =
model of contiguous memory,<br></div><div>which close mapping was surely a =
contributor to the success of C and then C++.</div><div><br></div><div>On T=
uesday, February 19, 2019 at 10:55:20 PM UTC-5, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;"></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">...I&#39;m curious as to what =
it is exactly about C++17&#39;s value category system that makes your propo=
sal possible where it was not possible before.</blockquote><div><br></div><=
div>I was referring to P0135 &quot;Guaranteed copy elision through simplifi=
ed value categories&quot;.</div><div>See e.g. Barry&#39;s blog=C2=A0<a href=
=3D"https://medium.com/@barryrevzin/value-categories-in-c-17-f56ae54bccbe">=
Value Categories in C++17</a>; &#39;copy&#39; initialization of a non-movab=
le type</div><div>is the usual example (some say &#39;elison&#39; is not th=
e right word - &#39;evasion&#39; may be more accurate).</div><div>I guess t=
hat array return could have been possible as a special case without this.</=
div></div><div><br></div><div>This proposed change allows a callee to alloc=
ate and return static array=C2=A0storage in the caller,</div><div>unwrapped=
 - array is already an aggregate, no need to conglomerate it.</div><div><br=
></div><div><div>Syntactically, inside-out &quot;declaration resembles usag=
e&quot; is a stumbling block,</div><div>though it is now nicely addressed w=
ith a using declaration;</div><div><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; overflow-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t N=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> carray </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">N</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">];</span></div></code></div></div><div><br></div><div>Again,=
 raw arrays, like raw pointers, are for low level code that calls for langu=
age expertise.</div><div>Poor syntax here could be seen as a feature as it =
puts off those who should not use it.</div><div><br></div><div>Ritchie call=
s out array-pointer relationship and declaration syntax as C&#39;s main iss=
ues</div><div>in the Critque section of <a href=3D"https://www.bell-labs.co=
m/usr/dmr/www/chist.html#">The Development of the C Language</a>,</div><div=
>which goes on to give several paragraphs on array:</div><div><br></div><bl=
ockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><span style=3D"color=
: rgb(0, 0, 0); font-family: &quot;Times New Roman&quot;; font-size: medium=
;">The other characteristic feature of C, its treatment of arrays, is more =
suspect on practical grounds, though it also has real virtues.<br></span><s=
pan style=3D"color: rgb(0, 0, 0); font-family: &quot;Times New Roman&quot;;=
 font-size: medium;">...<br></span>C&#39;s treatment of arrays in general (=
not just strings) has unfortunate implications both for optimization and fo=
r future extensions. The prevalence of pointers in C programs, whether thos=
e declared explicitly or arising from arrays, means that optimizers must be=
 cautious, and must use careful dataflow techniques to achieve good results=
.. Sophisticated compilers can understand what most pointers can possibly ch=
ange, but some important usages remain difficult to analyze. For example, f=
unctions with pointer arguments derived from arrays are hard to compile int=
o efficient code on vector machines, because it is seldom possible to deter=
mine that one argument pointer does not overlap data also referred to by an=
other argument, or accessible externally. More fundamentally, the definitio=
n of C so specifically describes the semantics of arrays that changes or ex=
tensions treating arrays as more primitive objects, and permitting operatio=
ns on them as wholes, become hard to fit into the existing language. Even e=
xtensions to permit the declaration and use of multidimensional arrays whos=
e size is determined dynamically are not entirely straightforward [MacDonal=
d 89] [Ritchie 90], although they would make it much easier to write numeri=
cal libraries in C. Thus, C covers the most important uses of strings and a=
rrays arising in practice by a uniform and simple mechanism, but leaves pro=
blems for highly efficient implementations and for extensions.</blockquote>=
<div><br></div><div>C++ has addressed most of these array critique points (=
apart from dynamic arrays...).</div>Highly efficient implementation is now =
possible. This extension to array return is possible.<br><div>C++&#39;s obj=
ect model addresses aliasing, so correct C++ code can be as efficient as Fo=
rtran.</div><div>As long as decay to pointer is avoided, the program retain=
s full information for array object-type.</div><div>References allow passin=
g sized arrays to functions, so &#39;permitting operations on them as whole=
s&#39;.</div><div><br></div><div>With references, passing array by value is=
 not necessary;</div><div>it is inconsistent that you cannot pass array by =
value but references make this unimportant.</div><div>Allowing a callee to =
allocate and return array static storage is more important, as functions ca=
n then</div><div>wrap array creation rather than taking as an argument a mu=
table reference to a pre-declared array.</div><div><br></div><div><div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;">C-array and std::array are differ=
ent tools for different tasks.</blockquote></div><div><br></div>The general=
 argument against your proposal is that they should not be viewed that way.=
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">That `std::array` ought to be viewed as fixed version of C-arrays</blockq=
uote><div><br>I was wrong to say &#39;different tools&#39;; C-array is a bu=
ilding block, std::array an edifice.</div></div><div>Similarly, although st=
d::array attempts to fix C-array, it has to do so by wrapping C-array.</div=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;">we should endeavor to make `std::array` more palatable in places where=
 it is problematic,=C2=A0</blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;">rather than trying to make C-arrays more functional.</=
blockquote><div><br></div><div>We should do both. This is C++; if we can, w=
e do.<br></div><div><br></div><div><div>std::array aimed at a strong data-h=
iding abstraction.</div></div><div>More recent additions to C++, like struc=
tured binding, make data more manifest.</div><div>Eventually, static reflec=
tion blows open all hidden data, including C-array members.</div><div>C-arr=
ay compatibility then grows in importance.</div><div><br></div><div>std::ar=
ray &#39;palatability&#39; improvement should be a new thread...</div><div>=
.... but, since it is raised here, let&#39;s totally raise the edifice and t=
ry to patch it up.</div><div><br></div><div>Here&#39;s a way to fork std::a=
rray:</div><div><br></div><div><div style=3D"color: #000000;background-colo=
r: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D=
"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"=
" 19px;white-space:=3D"" pre;"=3D""><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; overflow-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">size_t</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> E</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> array</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">template</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">size_t N</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> array</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">N</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=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</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> T data</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">N</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">]{};</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// std array</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">size_t N</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> array</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=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</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">/* ? */</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// </span><span style=3D"color: rgb(136, 0, 0);"><span style=3D"color=
: #800;" class=3D"styled-by-prettify">improved array</span></span></div></c=
ode></div><div><br></div>Then <font face=3D"courier new, monospace"><span c=
lass=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250);"=
>std::array</span><span class=3D"styled-by-prettify" style=3D"background-co=
lor: rgb(250, 250, 250); color: rgb(102, 102, 0);">&lt;</span><span class=
=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250); colo=
r: rgb(0, 0, 136);">int</span><span class=3D"styled-by-prettify" style=3D"b=
ackground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">[</span><spa=
n class=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250=
); color: rgb(0, 102, 102);">4</span></font><span class=3D"styled-by-pretti=
fy" style=3D"background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);=
"><font face=3D"courier new, monospace">]&gt;</font>=C2=A0</span>gives a ne=
w improved array.</div></div><div style=3D"color: #000000;background-color:=
 #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D""=
 monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" =
19px;white-space:=3D"" pre;"=3D""><br></div><div style=3D"color: #000000;ba=
ckground-color: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"=
" courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;lin=
e-height:=3D"" 19px;white-space:=3D"" pre;"=3D"">This way, we could also ad=
d=C2=A0<font face=3D"courier new, monospace"><span class=3D"styled-by-prett=
ify" style=3D"background-color: rgb(250, 250, 250);">std</span><span class=
=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250, 250); colo=
r: rgb(102, 102, 0);">::</span></font><span class=3D"styled-by-prettify" st=
yle=3D"background-color: rgb(250, 250, 250);"><font face=3D"courier new, mo=
nospace">array_ref</font> as a reference wrapper specific to C-array -</spa=
n></div><div style=3D"color: #000000;background-color: #fffffe;font-family:=
 Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monospace;font-weigh=
t:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-space:=3D"=
" pre;"=3D"">a std compatibility wrapper for existing C-array, including mu=
lti-dimensional.</div><div style=3D"color: #000000;background-color: #fffff=
e;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monosp=
ace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;wh=
ite-space:=3D"" pre;"=3D""><br></div><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> m44</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
][</span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>array_ref</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">m44</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// copyable, copy-assignable from array, comparable, et=
c.</span></div></code></div><div style=3D"color: #000000;background-color: =
#fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" =
monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 1=
9px;white-space:=3D"" pre;"=3D""><br></div><div style=3D"color: #000000;bac=
kground-color: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D""=
 courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line=
-height:=3D"" 19px;white-space:=3D"" pre;"=3D""><div style=3D"color: rgb(34=
, 34, 34); background-color: rgb(255, 255, 255);">Strange how &#39;two worl=
d-view&#39; conflict burns on; I hadn&#39;t mean to spark flame-wars of old=
</div><div style=3D"color: rgb(34, 34, 34); background-color: rgb(255, 255,=
 255);">(weren&#39;t flame wars fought between languages, not one language =
burning its foundation).=C2=A0</div></div><div><br></div><div>On Tuesday, F=
ebruary 19, 2019 at 10:55:20 PM UTC-5, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">On Tuesday, February 19, 2019 =
at 10:52:40 AM UTC-5, will wray wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">(Trying one more time - previous attempts went to the g=
oogle groups spam filter)<br><div><br><span style=3D"font-family:Roboto,&qu=
ot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:small">C-array=
 is an atomic aggregate - a pure crystal condensate of one atom type.</span=
><div><font size=3D"2" face=3D"Roboto, Helvetica Neue, Helvetica, Arial, sa=
ns-serif"><br></font><div><div><div><span style=3D"font-family:Roboto,&quot=
;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:small">This thre=
ad is to discuss improved language support for C-array via array return.</s=
pan></div><div><span style=3D"font-family:Roboto,&quot;Helvetica Neue&quot;=
,Helvetica,Arial,sans-serif;font-size:small"><br></span></div><div><span st=
yle=3D"font-family:Roboto,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-s=
erif;font-size:small">(It is not about addressing std::array shortcomings.<=
/span></div><div><span style=3D"font-family:Roboto,&quot;Helvetica Neue&quo=
t;,Helvetica,Arial,sans-serif;font-size:small">=C2=A0It is not an either / =
or.=C2=A0</span></div><div>=C2=A0C-array and std::array are different tools=
 for different tasks.)</div></div></div></div></div></div></blockquote><div=
><br></div><div>The general argument against your proposal is that they sho=
uld not be viewed that way. That `std::array` ought to be viewed as fixed v=
ersion of C-arrays, and we should endeavor to make `std::array` more palata=
ble in places where it is problematic, rather than trying to make C-arrays =
more functional.<br><br>It&#39;s a conflict of world-views. You see C-array=
s as an inherent good that should be brought up to parity with other langua=
ge features. Others see C-arrays as a necessary evil which should be margin=
alized as much as possible by providing alternatives (`std::array`, `std::s=
pan`, etc) that work more naturally with C++&#39;s rules.</div><div><br></d=
iv><div>From a more objective POV, my feeling is that `std::array` really o=
nly has two significant flaws relative to to C arrays: not being able to om=
it the size of an array while still specifying the type (which is a matter =
of CTAD), and the general verbosity of multi-dimensional arrays. The fact t=
hat `data()` returns a pointer is irrelevant in a world where `std::span` c=
an be used for taking references to sized arrays. `std::array&lt;T,N&gt;` i=
s convertible to a `std::span&lt;T, N&gt;` or to a dynamically sized span; =
that&#39;s good enough.<br></div><div><br></div><div>On a personal level, t=
he biggest problem I have with increasing the use of C-arrays is syntactic.=
 Just look at one of your examples:<br><br>char abc1D()[3] { return {&#39;a=
&#39;,&#39;b&#39;,&#39;c&#39;}; }<br><br>If the `[3]` applies to the `char`=
 as part of the return type, why is it on the other side of the function na=
me? The return type should be either on the left or the right; it shouldn&#=
39;t be scattered between them. My first thought was that you were somehow =
creating an array of functions, not a function that returns an array.<br><b=
r>By contrast:<br><br>std::array&lt;char, 3&gt; abc1D();<br><br>That looks =
like a regular function returning a regular type. The entirety of the retur=
n type is in one place in the function declaration. It may be more verbose =
than your version, but that regularity and consistency has its place.<br><b=
r>Contrast this to GLSL, where arrays can in fact be return values. In that=
 syntax, the array size is visually (or can be written as) part of the type=
.. You can write `float[30] array`, rather than `float array[30]` (though th=
e latter works too). So when you return an array, you do `float[10] func_na=
me(...)`.</div><div><br></div><div>GLSL of course had the advantage that po=
inters don&#39;t exist, so there are no decay-to-pointer rules...<br></div>=
<div><br></div><div>Also, there is a problem of a lack of consistency. If y=
ou can return an array by value, and you can declare a variable that is an =
array which receives that array by value... why can&#39;t you pass an array=
 by value to a function? Because `void func(char arr[3])` still just takes =
a pointer, not an array. And you can&#39;t fix that, since it would be a br=
eaking change. By contrast, `void func(std::span&lt;char, 3&gt; arr)` is no=
t a lie; you cannot just pass a pointer to that.<br></div><div><br>Encourag=
ing the use of C-arrays in the way you suggest is kind of a lie. Right now,=
 arrays are not regular types; they are objects, but they&#39;re not regula=
r types. Being able to return them by value suggests that they are value ty=
pes, but it only makes them value types in one case.<br><br>Also, I&#39;m c=
urious as to what it is exactly about C++17&#39;s value category system tha=
t makes your proposal possible where it was not possible before.<br></div><=
br></div></blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/2cbcb629-3c44-47f3-931a-126196f0a485%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2cbcb629-3c44-47f3-931a-126196f0a485=
%40isocpp.org</a>.<br />

------=_Part_1904_744185688.1550680141906--

------=_Part_1903_175351419.1550680141905--

.

On 19/02/2019 11.30, Jake Arkinstall wrote:
> On Tue, 19 Feb 2019, 15:52 will wray wrote:
>> Raw arrays deserve to be rehabilitated, with a little language level love.
>
> I'm not so sure on that. std::array gives the compiler the knowledge of the
> size so that the user doesn't have to pass it around manually

Eh?

  void foo(int (&arr)[4]);
  void foo(std::array<int, 4>& arr);

The compiler knows the size in both cases. I guess you are comparing to:

  void foo(int arr[]);

....but that's not really apples-to-apples, being closer to:

  void (int* arr);

--
Matthew

--
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/cad40ae7-e6e4-4c75-d954-5ecc7d6fc57e%40gmail.com.

.

On 19/02/2019 22.55, Nicol Bolas wrote:
> From a more objective POV, my feeling is that `std::array` really only has
> two significant flaws relative to to C arrays: not being able to omit the
> size of an array while still specifying the type (which is a matter of
> CTAD), and the general verbosity of multi-dimensional arrays.

Well, I can help with the second... shortest ever proposal?

  namespace std
  {
    template <typename T, size_t First, size_t... N>
    struct array : array<array<T, N...>, First> {};
  }

Example:

  std::array<int, 5, 3, 4> x;
  x[1][1][1] = 42;

Implementing operator() to do multi-level indexing is left as an
exercise for the reader.

Of course, the reason we don't have this yet is because folks want to
argue about packing order and whatnot. It turns out multi-dimensional
arrays aren't actually as simple as you'd think.

--
Matthew

--
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/1e6e2f7e-cc29-7f39-f421-3674cd71ce14%40gmail.com.

.

--000000000000ff833405825874b7
Content-Type: text/plain; charset="UTF-8"

Except sometimes, when they are, and this is exactly what one would need.

On Wed, Feb 20, 2019 at 7:33 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 19/02/2019 22.55, Nicol Bolas wrote:
> > From a more objective POV, my feeling is that `std::array` really only
> has
> > two significant flaws relative to to C arrays: not being able to omit
> the
> > size of an array while still specifying the type (which is a matter of
> > CTAD), and the general verbosity of multi-dimensional arrays.
>
> Well, I can help with the second... shortest ever proposal?
>
>   namespace std
>   {
>     template <typename T, size_t First, size_t... N>
>     struct array : array<array<T, N...>, First> {};
>   }
>
> Example:
>
>   std::array<int, 5, 3, 4> x;
>   x[1][1][1] = 42;
>
> Implementing operator() to do multi-level indexing is left as an
> exercise for the reader.
>
> Of course, the reason we don't have this yet is because folks want to
> argue about packing order and whatnot. It turns out multi-dimensional
> arrays aren't actually as simple as you'd think.
>
> --
> Matthew
>
> --
> 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/1e6e2f7e-cc29-7f39-f421-3674cd71ce14%40gmail.com
> .
>

--
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/CAANG%3DkUNY_JP7KSOHQ9bnYog-PQhUoBx97qniVgXCs%2BoZRkYiA%40mail.gmail.com.

--000000000000ff833405825874b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Except sometimes, when they are, and this is exactly what =
one would need.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Feb 20, 2019 at 7:33 PM Matthew Woehlke &lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 19/02/2019 =
22.55, Nicol Bolas wrote:<br>
&gt; From a more objective POV, my feeling is that `std::array` really only=
 has <br>
&gt; two significant flaws relative to to C arrays: not being able to omit =
the <br>
&gt; size of an array while still specifying the type (which is a matter of=
 <br>
&gt; CTAD), and the general verbosity of multi-dimensional arrays.<br>
<br>
Well, I can help with the second... shortest ever proposal?<br>
<br>
=C2=A0 namespace std<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 template &lt;typename T, size_t First, size_t... N&gt;<br>
=C2=A0 =C2=A0 struct array : array&lt;array&lt;T, N...&gt;, First&gt; {};<b=
r>
=C2=A0 }<br>
<br>
Example:<br>
<br>
=C2=A0 std::array&lt;int, 5, 3, 4&gt; x;<br>
=C2=A0 x[1][1][1] =3D 42;<br>
<br>
Implementing operator() to do multi-level indexing is left as an<br>
exercise for the reader.<br>
<br>
Of course, the reason we don&#39;t have this yet is because folks want to<b=
r>
argue about packing order and whatnot. It turns out multi-dimensional<br>
arrays aren&#39;t actually as simple as you&#39;d think.<br>
<br>
-- <br>
Matthew<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/1e6e2f7e-cc29-7f39-f421-3674cd71ce14%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/1e6e2f7e-cc29-7f39-f421-3674cd71ce14%40=
gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAANG%3DkUNY_JP7KSOHQ9bnYog-PQhUoBx97=
qniVgXCs%2BoZRkYiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUNY_=
JP7KSOHQ9bnYog-PQhUoBx97qniVgXCs%2BoZRkYiA%40mail.gmail.com</a>.<br />

--000000000000ff833405825874b7--

.

On 02/20/2019 03:55 AM, Nicol Bolas wrote:
>=20
> On a personal level, the biggest problem I have with increasing the use o=
f C-arrays is syntactic. Just look at one of your examples:
>=20
> char abc1D()[3] { return {'a','b','c'}; }
>=20
> If the `[3]` applies to the `char` as part of the return type, why is it =
on the other side of the function name? The return type should be either on=
 the left or the right; it shouldn't be scattered between them. My first th=
ought was that you were somehow creating an array of functions, not a funct=
ion that returns an array.

Not arguing for this in any way, but I'd think that
syntax-wise, this would be much clearer:

 auto abc1D()-> char[3] { return {'a','b','c'}; }

Curiously, seems like that actually compiled with GCC up until v7.  See:

  https://godbolt.org/z/aE5l8I

gcc 8 errors out with
 error: 'abc1D' declared as function returning an array
and clang errors out with
 error: function cannot return array type 'char [3]'

Pedro Alves

--=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/c3d59504-0492-91bb-4271-85fc9449d725%40palves.ne=
t.

.

On 02/21/2019 11:48 AM, Pedro Alves wrote:
> On 02/20/2019 03:55 AM, Nicol Bolas wrote:
>>
>> On a personal level, the biggest problem I have with increasing the use =
of C-arrays is syntactic. Just look at one of your examples:
>>
>> char abc1D()[3] { return {'a','b','c'}; }
>>
>> If the `[3]` applies to the `char` as part of the return type, why is it=
 on the other side of the function name? The return type should be either o=
n the left or the right; it shouldn't be scattered between them. My first t=
hought was that you were somehow creating an array of functions, not a func=
tion that returns an array.
>=20
> Not arguing for this in any way, but I'd think that
> syntax-wise, this would be much clearer:
>=20
>  auto abc1D()-> char[3] { return {'a','b','c'}; }
>=20
> Curiously, seems like that actually compiled with GCC up until v7.  See:
>=20
>   https://godbolt.org/z/aE5l8I
>=20
> gcc 8 errors out with
>  error: 'abc1D' declared as function returning an array
> and clang errors out with
>  error: function cannot return array type 'char [3]'

Also curiously, and for completeness, I should add that all of gcc,
clang and msvc already parse the proposed syntax as intended:

 https://godbolt.org/z/q848pW

As can be seen from the error messages (here gcc):

  <source>:1:15: error: 'abc1D' declared as function returning an array

I couldn't find a gcc version that actually accepts that syntax without
error, unlike the trailing return type version.

This seems to suggest that the syntax would be a natural fit
for the grammar, at least.

Pedro Alves

--=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/11bb7203-29aa-31cc-68e3-15d96fd1306e%40palves.ne=
t.

.