------=_Part_8469_612590265.1529089382996
Content-Type: multipart/alternative;
 boundary="----=_Part_8470_820717651.1529089382997"

------=_Part_8470_820717651.1529089382997
Content-Type: text/plain; charset="UTF-8"

Hi,

wild idea, fix C-style arrays so they are copyable as any other builtin
types.

Currently following code compiles
void foo(int arr[4]);

int main()
{
    int *a;
    int b[3];
    foo(a);
    foo(b);
}

this is because type of foo is actually void (int *).

Let's ban by value array types in function parameters.
This should open door for allowing copying arrays in automatic variables,
and data members, e.g.:

int main()
{
    int a[3] = {1, 2, 3, 4};
    int b[3] = a;
    auto c = a; // c should deduce to int [3]
}

Passing array to function will not be ambiguous anymore, as either you will
pass it by pointer or reference to array (as currently), i.e.

void foo(int *arr);
void bar(int (&arr)[3]);

int main()
{
    int a[3] = {1, 2, 3};
    foo(a);
    bar(a);
}

When enough time pass we can allow void foo(int arr[3]) again but we fixed
behavior.

Regards,
Maciej

--
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/d30c82a1-338e-42c7-aded-e341070821f9%40isocpp.org.

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

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>wild idea, fix C-style a=
rrays so they are copyable as any other builtin types.</div><div><br></div>=
<div>Currently following code compiles<br></div><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> arr</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">]);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span 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"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><spa=
n 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 style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 foo</span><span style=3D"co=
lor: #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"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 foo</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">b</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an></div></code></div><div><br></div><div></div><div>this is because type o=
f foo is actually void (int *).</div><div><br></div><div>Let&#39;s ban by v=
alue array types in function parameters.</div><div>This should open door fo=
r allowing copying arrays in automatic variables, and data members, e.g.:</=
div><div><br></div><div>int main()</div><div>{</div><div>=C2=A0=C2=A0=C2=A0=
 int a[3] =3D {1, 2, 3, 4};</div><div>=C2=A0=C2=A0=C2=A0 int b[3] =3D a;</d=
iv><div>=C2=A0=C2=A0=C2=A0 auto c =3D a; // c should deduce to int [3]<br><=
/div><div>}</div><div><br></div><div>Passing array to function will not be =
ambiguous anymore, as either you will pass it by pointer or reference to ar=
ray (as currently), i.e.</div><div><br></div><div>void foo(int *arr);</div>=
<div>void bar(int (&amp;arr)[3]);</div><div><br></div><div>int main()</div>=
<div>{</div><div>=C2=A0=C2=A0=C2=A0  int a[3] =3D {1, 2, 3};</div><div>=C2=
=A0=C2=A0=C2=A0 foo(a);</div><div>=C2=A0=C2=A0=C2=A0 bar(a);<br></div><div>=
}</div><div><br></div><div>When enough time pass we can allow void foo(int =
arr[3]) again but we fixed behavior.</div><div><br></div><div>Regards,</div=
><div>Maciej<br></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/d30c82a1-338e-42c7-aded-e341070821f9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d30c82a1-338e-42c7-aded-e341070821f9=
%40isocpp.org</a>.<br />

------=_Part_8470_820717651.1529089382997--

------=_Part_8469_612590265.1529089382996--

.

On 2018-06-15 21:03, m.cencora@gmail.com wrote:
> Hi,
>=20
> wild idea, fix C-style arrays so they are copyable as any other builtin=
=20
> types.
>=20
> Currently following code compiles
> |
> voidfoo(intarr[4]);
>=20
> intmain()
> {
> int*a;
> intb[3];
>  =C2=A0 =C2=A0 foo(a);
>  =C2=A0 =C2=A0 foo(b);
> }
> |
>=20
> this is because type of foo is actually void (int *).
>=20
> Let's ban by value array types in function parameters.
> This should open door for allowing copying arrays in automatic=20
> variables, and data members, e.g.:
>=20
> int main()
> {
>  =C2=A0=C2=A0=C2=A0 int a[3] =3D {1, 2, 3, 4};
>  =C2=A0=C2=A0=C2=A0 int b[3] =3D a;
>  =C2=A0=C2=A0=C2=A0 auto c =3D a; // c should deduce to int [3]
> }
>=20
> Passing array to function will not be ambiguous anymore, as either you=20
> will pass it by pointer or reference to array (as currently), i.e.
>=20
> void foo(int *arr);
> void bar(int (&arr)[3]);
>=20
> int main()
> {
>  =C2=A0=C2=A0=C2=A0 int a[3] =3D {1, 2, 3};
>  =C2=A0=C2=A0=C2=A0 foo(a);
>  =C2=A0=C2=A0=C2=A0 bar(a);
> }
>=20
> When enough time pass we can allow void foo(int arr[3]) again but we=20
> fixed behavior.
>=20

Atempts at fixing C style arrays were rejected already before the first=20
C++ standard. It was deemed Not Fixable.

Instead we got std::vector and later std::array.

If Dennis Ritchie thought it was too late to change it in the 1970's,=20
how late isn't it now?


     Bo Persson


--=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/pg1di2%24saf%241%40blaine.gmane.org.

.

On Friday, 15 June 2018 12:03:02 PDT m.cencora@gmail.com wrote:
> Let's ban by value array types in function parameters.

int main(int argv, char *argv[])

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/16270308.36AUhQ6yky%40tjmaciei-mobl1.

.

------=_Part_10262_1646268533.1529127041957
Content-Type: multipart/alternative;
 boundary="----=_Part_10263_725744673.1529127041957"

------=_Part_10263_725744673.1529127041957
Content-Type: text/plain; charset="UTF-8"

int main(int argv, char *argv[])

This is not what I meant by 'by value array parameter'. What I meant is an
array where the dimension is specified.

So the case you mention is not changed. Arrays are still implicitly
convertible to pointer to first element.
I want to ban the by value array parameters because they are ambiguous -
and it can be easily be fixed by changing this param to type * (without
changing API/ABI) or type (&)[N] (to increase type safety).
This ban alone is worth pursuing as it get rids of another C++ wierdness.

Currently this program is ill-formed:
void foo(char a[3]) {}
void foo(char a[5]) {} // error: function redefinition



--
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/b6c027d6-72fa-409a-a5ce-8dfed4406f17%40isocpp.org.

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

<div dir=3D"ltr"><div>int main(int argv, char *argv[])</div><div><br></div>=
<div>This is not what I meant by &#39;by value array parameter&#39;. What I=
 meant is an array where the dimension is specified.</div><div><br></div><d=
iv>So the case you mention is not changed. Arrays are still implicitly conv=
ertible to pointer to first element.<br></div><div>I want to ban the by val=
ue array parameters because they are ambiguous - and it can be easily be fi=
xed by changing this param to type * (without changing API/ABI) or type (&a=
mp;)[N] (to increase type safety).<br></div><div>This ban alone is worth pu=
rsuing as it get rids of another C++ wierdness.</div><div><br></div><div>Cu=
rrently this program is ill-formed:<br></div><div style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">char</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: #066;" class=3D"styled-by-prettify">3</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: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">char</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">5</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">{}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// error: function redefinition</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><div><=
br><br></div><div><br> <iframe style=3D"padding: 0px; position: absolute; t=
op: 0px; left: 0px; width: 1047px; height: 188px; visibility: hidden;" fram=
eborder=3D"0"></iframe></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/b6c027d6-72fa-409a-a5ce-8dfed4406f17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6c027d6-72fa-409a-a5ce-8dfed4406f17=
%40isocpp.org</a>.<br />

------=_Part_10263_725744673.1529127041957--

------=_Part_10262_1646268533.1529127041957--

.

------=_Part_10903_320974389.1529142210260
Content-Type: multipart/alternative;
 boundary="----=_Part_10904_1277135979.1529142210261"

------=_Part_10904_1277135979.1529142210261
Content-Type: text/plain; charset="UTF-8"

How can you ban something like that without braking existing code?

You can't. Not until we have some amazing and magical refactoring tools.
And even if fixed for the C++, you break C compatibility by definition.

I agree C++ must evolve, dropping/streamlining features, but this breaks a
lot and you gain basically nothing as you can use array and span to create
modern interfaces.


On Friday, June 15, 2018 at 10:03:03 PM UTC+3, m.ce...@gmail.com wrote:
>
> Hi,
>
> wild idea, fix C-style arrays so they are copyable as any other builtin
> types.
>
> Currently following code compiles
> void foo(int arr[4]);
>
> int main()
> {
>     int *a;
>     int b[3];
>     foo(a);
>     foo(b);
> }
>
> this is because type of foo is actually void (int *).
>
> Let's ban by value array types in function parameters.
> This should open door for allowing copying arrays in automatic variables,
> and data members, e.g.:
>
> int main()
> {
>     int a[3] = {1, 2, 3, 4};
>     int b[3] = a;
>     auto c = a; // c should deduce to int [3]
> }
>
> Passing array to function will not be ambiguous anymore, as either you
> will pass it by pointer or reference to array (as currently), i.e.
>
> void foo(int *arr);
> void bar(int (&arr)[3]);
>
> int main()
> {
>     int a[3] = {1, 2, 3};
>     foo(a);
>     bar(a);
> }
>
> When enough time pass we can allow void foo(int arr[3]) again but we fixed
> behavior.
>
> Regards,
> Maciej
>

--
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/396859e3-cc0d-48d3-880b-e95447c04d7c%40isocpp.org.

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

<div dir=3D"ltr"><div>How can you ban something like that without braking e=
xisting code?</div><div><br></div><div>You can&#39;t. Not until we have som=
e amazing and magical refactoring tools. And even if fixed for the C++, you=
 break C compatibility by definition.=C2=A0</div><div><br></div><div>I agre=
e C++ must evolve, dropping/streamlining features, but this breaks a lot an=
d you gain basically nothing as you can use array and span to create modern=
 interfaces.=C2=A0</div><div><br></div><br>On Friday, June 15, 2018 at 10:0=
3:03 PM UTC+3, m.ce...@gmail.com wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>wild idea, fix =
C-style arrays so they are copyable as any other builtin types.</div><div><=
br></div><div>Currently following code compiles<br></div><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px"><code><div><span style=3D"color:#008">void</span><spa=
n style=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">int</span><span style=3D"color:#000"> arr</span><span =
style=3D"color:#660">[</span><span style=3D"color:#066">4</span><span style=
=3D"color:#660">]);</span><span style=3D"color:#000"><br><br></span><span s=
tyle=3D"color:#008">int</span><span style=3D"color:#000"> main</span><span =
style=3D"color:#660">()</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color:#008">int</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">*</span><span style=3D"color:#000">a</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#008">int</span><span style=3D"color:#000">=
 b</span><span style=3D"color:#660">[</span><span style=3D"color:#066">3</s=
pan><span style=3D"color:#660">];</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 foo</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">a</span><span style=3D"color:#660">);</span><span style=3D"color:#0=
00"><br>=C2=A0 =C2=A0 foo</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">b</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div></code>=
</div><div><br></div><div></div><div>this is because type of foo is actuall=
y void (int *).</div><div><br></div><div>Let&#39;s ban by value array types=
 in function parameters.</div><div>This should open door for allowing copyi=
ng arrays in automatic variables, and data members, e.g.:</div><div><br></d=
iv><div>int main()</div><div>{</div><div>=C2=A0=C2=A0=C2=A0 int a[3] =3D {1=
, 2, 3, 4};</div><div>=C2=A0=C2=A0=C2=A0 int b[3] =3D a;</div><div>=C2=A0=
=C2=A0=C2=A0 auto c =3D a; // c should deduce to int [3]<br></div><div>}</d=
iv><div><br></div><div>Passing array to function will not be ambiguous anym=
ore, as either you will pass it by pointer or reference to array (as curren=
tly), i.e.</div><div><br></div><div>void foo(int *arr);</div><div>void bar(=
int (&amp;arr)[3]);</div><div><br></div><div>int main()</div><div>{</div><d=
iv>=C2=A0=C2=A0=C2=A0  int a[3] =3D {1, 2, 3};</div><div>=C2=A0=C2=A0=C2=A0=
 foo(a);</div><div>=C2=A0=C2=A0=C2=A0 bar(a);<br></div><div>}</div><div><br=
></div><div>When enough time pass we can allow void foo(int arr[3]) again b=
ut we fixed behavior.</div><div><br></div><div>Regards,</div><div>Maciej<br=
></div></div></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/396859e3-cc0d-48d3-880b-e95447c04d7c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/396859e3-cc0d-48d3-880b-e95447c04d7c=
%40isocpp.org</a>.<br />

------=_Part_10904_1277135979.1529142210261--

------=_Part_10903_320974389.1529142210260--

.

On Friday, 15 June 2018 22:30:41 PDT m.cencora@gmail.com wrote:
> Currently this program is ill-formed:
> void foo(char a[3]) {}
> void foo(char a[5]) {} // error: function redefinition

Correct. But if you leave one of the two lines, it's valid. So you'd need to
deprecate now in order to be able to reuse the syntax sometime 10 years from
now.

And convince the C standard. We're not going to deviate from the C standard
when it comes to C arrays.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1931565.NZ5iu3KGHu%40tjmaciei-mobl1.

.

On June 16, 2018 8:57 AM, Thiago Macieira <thiago@macieira.org> wrote:
>=20
> >=20
> > void foo(char a[3]) {}
>=20
> So you'd need to
> deprecate now in order to be able to reuse the syntax sometime 10 years f=
rom
> now.
>=20
> And convince the C standard. We're not going to deviate from the C standa=
rd
> when it comes to C arrays.
>=20

The C standard does want to move away from this
semantics, and that's why they added

  void foo(char a[static 3]);

syntax.  But C did not deprecated the old syntax,
just like they still have `void foo()` to mean a prototype
accepting any arguments... On this topic I wish C++
can do better, just like what we did to `void foo()`.

=E2=80=8B--

Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________=E2=80=8B

--=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/847fzLmq9CJnk_CrSCL3i-X3bYiEvIRdHUuKuRcO8x5qpOtM=
H4bhtpHZ8giL8XrLSZb8jNykh9P-XpzJOYcGzTM_bwffUZGzfcaul1p-wAI%3D%40miator.net=
..

.

------=_Part_15782_2145734201.1529255749909
Content-Type: multipart/alternative;
 boundary="----=_Part_15783_2030218601.1529255749909"

------=_Part_15783_2030218601.1529255749909
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

W dniu sobota, 16 czerwca 2018 15:57:05 UTC+2 u=C5=BCytkownik Thiago Maciei=
ra=20
napisa=C5=82:
>
> On Friday, 15 June 2018 22:30:41 PDT m.ce...@gmail.com <javascript:>=20
> wrote:=20
> > Currently this program is ill-formed:=20
> > void foo(char a[3]) {}=20
> > void foo(char a[5]) {} // error: function redefinition=20
>
> Correct. But if you leave one of the two lines, it's valid. So you'd need=
=20
> to=20
> deprecate now in order to be able to reuse the syntax sometime 10 years=
=20
> from=20
> now.=20
>

It is valid but it is ambiguous - go explain newcomer why the a param=20
inside this function may be an array of any size (or may not be an array at=
=20
all!).
Isn't it worth to get right of this buggy behavior?
=20

>
> And convince the C standard. We're not going to deviate from the C=20
> standard=20
> when it comes to C arrays.=20
>

We already do - C++ does not allow following C99 syntax:
void foo(char arr[static 3]);



> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
>
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e9698bd4-21b8-4c63-b491-f475f8a3196e%40isocpp.or=
g.

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

<div dir=3D"ltr">W dniu sobota, 16 czerwca 2018 15:57:05 UTC+2 u=C5=BCytkow=
nik Thiago Macieira napisa=C5=82:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">On Friday, 15 June 2018 22:30:41 PDT <a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"DcFm_PItAwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">m.ce...@gmail.com</a> wrote:
<br>&gt; Currently this program is ill-formed:
<br>&gt; void foo(char a[3]) {}
<br>&gt; void foo(char a[5]) {} // error: function redefinition
<br>
<br>Correct. But if you leave one of the two lines, it&#39;s valid. So you&=
#39;d need to=20
<br>deprecate now in order to be able to reuse the syntax sometime 10 years=
 from=20
<br>now.
<br></blockquote><div><br></div><div>It is valid but it is ambiguous - go e=
xplain newcomer why the a param inside this function may be an array of any=
 size (or may not be an array at all!).</div><div>Isn&#39;t it worth to get=
 right of this buggy behavior?<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>And convince the C standard. We&#39;re not going to deviate from the C =
standard=20
<br>when it comes to C arrays.
<br></blockquote><div><br></div><div>We already do - C++ does not allow fol=
lowing C99 syntax:</div><div><div style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
char</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> arr</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">static</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">]);</span></div></code></div><br></div><div=
> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<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/e9698bd4-21b8-4c63-b491-f475f8a3196e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e9698bd4-21b8-4c63-b491-f475f8a3196e=
%40isocpp.org</a>.<br />

------=_Part_15783_2030218601.1529255749909--

------=_Part_15782_2145734201.1529255749909--

.

On Sunday, 17 June 2018 10:15:49 PDT m.cencora@gmail.com wrote:
> > > Currently this program is ill-formed:
> > > void foo(char a[3]) {}
> > > void foo(char a[5]) {} // error: function redefinition
> >
> > Correct. But if you leave one of the two lines, it's valid. So you'd need
> > to
> > deprecate now in order to be able to reuse the syntax sometime 10 years
> > from
> > now.
>
> It is valid but it is ambiguous - go explain newcomer why the a param
> inside this function may be an array of any size (or may not be an array at
> all!).
> Isn't it worth to get right of this buggy behavior?

Maybe. So deprecate this now. We can maybe fix it sometime in the 2030s.

You'll also have to convince the C committee why you don't want to use their
syntax

 void foo(char a[static 3]);

> > And convince the C standard. We're not going to deviate from the C
> > standard
> > when it comes to C arrays.
>
> We already do - C++ does not allow following C99 syntax:
> void foo(char arr[static 3]);

Where in the C++ standard does it say that's allowed?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/3057815.irFFbh7s3k%40tjmaciei-mobl1.

.

On Sunday, 17 June 2018 18:56:14 PDT Thiago Macieira wrote:
> And convince the C standard. We're not going to deviate from the C
>
> > > standard
> > > when it comes to C arrays.
> >
> > We already do - C++ does not allow following C99 syntax:
> > void foo(char arr[static 3]);
>
> Where in the C++ standard does it say that's allowed?

Never mind, rereading your sentence.

We do not have a new feature that C added in C99 and almost no one uses. I've
NEVER seen any code base using that, I don't know of a compiler that actually
handles it instead of just ignoring it.

C++ doesn't want this feature because we don't need it. We have this thing
called a "class" that allows us to have what we need. So you can't use this as
an example of why it's ok to deviate from C, since this very case is also a
counter-argument for your request.

Note I have nothing against deprecating the misleading
 void foo(char arr[3]);

But I don't think we should repurpose that without aligning with the C
committee. I don't think we should repurpose it at all, actually.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/7807832.Y1LdAodfR9%40tjmaciei-mobl1.

.

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

Newer versions of clang handle it.

On Sun, Jun 17, 2018 at 10:01 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Sunday, 17 June 2018 18:56:14 PDT Thiago Macieira wrote:
> > And convince the C standard. We're not going to deviate from the C
> >
> > > > standard
> > > > when it comes to C arrays.
> > >
> > > We already do - C++ does not allow following C99 syntax:
> > > void foo(char arr[static 3]);
> >
> > Where in the C++ standard does it say that's allowed?
>
> Never mind, rereading your sentence.
>
> We do not have a new feature that C added in C99 and almost no one uses.
> I've
> NEVER seen any code base using that, I don't know of a compiler that
> actually
> handles it instead of just ignoring it.
>
> C++ doesn't want this feature because we don't need it. We have this thing
> called a "class" that allows us to have what we need. So you can't use
> this as
> an example of why it's ok to deviate from C, since this very case is also
> a
> counter-argument for your request.
>
> Note I have nothing against deprecating the misleading
>         void foo(char arr[3]);
>
> But I don't think we should repurpose that without aligning with the C
> committee. I don't think we should repurpose it at all, actually.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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/7807832.Y1LdAodfR9%40tjmaciei-mobl1.
>

--
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/CAMD6iD9QC0mYi_HKhVFOq0awCaYRRNum2G%3Dx%3D0uNqArARX5RPA%40mail.gmail.com.

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

<div dir=3D"ltr">Newer versions of clang handle it.</div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Sun, Jun 17, 2018 at 10:01 PM, T=
hiago Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org"=
 target=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><span class=3D"">On Sunday, 17 June 2018 18:56:14 PDT T=
hiago Macieira wrote:<br>
&gt; And convince the C standard. We&#39;re not going to deviate from the C=
<br>
&gt; <br>
&gt; &gt; &gt; standard<br>
&gt; &gt; &gt; when it comes to C arrays.<br>
&gt; &gt; <br>
&gt; &gt; We already do - C++ does not allow following C99 syntax:<br>
&gt; &gt; void foo(char arr[static 3]);<br>
&gt; <br>
&gt; Where in the C++ standard does it say that&#39;s allowed?<br>
<br>
</span>Never mind, rereading your sentence.<br>
<br>
We do not have a new feature that C added in C99 and almost no one uses. I&=
#39;ve <br>
NEVER seen any code base using that, I don&#39;t know of a compiler that ac=
tually <br>
handles it instead of just ignoring it.<br>
<br>
C++ doesn&#39;t want this feature because we don&#39;t need it. We have thi=
s thing <br>
called a &quot;class&quot; that allows us to have what we need. So you can&=
#39;t use this as <br>
an example of why it&#39;s ok to deviate from C, since this very case is al=
so a <br>
counter-argument for your request.<br>
<br>
Note I have nothing against deprecating the misleading<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 void foo(char arr[3]);<br>
<br>
But I don&#39;t think we should repurpose that without aligning with the C =
<br>
committee. I don&#39;t think we should repurpose it at all, actually.<br>
<span class=3D""><br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<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">std-propo=
sals+unsubscribe@<wbr>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>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/7807832.Y1LdAodfR9%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wb=
r>isocpp.org/d/msgid/std-<wbr>proposals/7807832.Y1LdAodfR9%<wbr>40tjmaciei-=
mobl1</a>.<br>
</blockquote></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/CAMD6iD9QC0mYi_HKhVFOq0awCaYRRNum2G%3=
Dx%3D0uNqArARX5RPA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9QC0mY=
i_HKhVFOq0awCaYRRNum2G%3Dx%3D0uNqArARX5RPA%40mail.gmail.com</a>.<br />

--000000000000a9b41c056ee1f5fc--

.

On June 17, 2018 9:01 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
> We do not have a new feature that C added in C99 and almost no one uses.

As a data point, I use it.

> You'll also have to convince the C committee why you don't want to use their syntax

Because static array bound is a different feature:
for char arr[static 3], arr in function body is still a
char*, not char[3].

>
> C++ doesn't want this feature because we don't need it. We have this thing
> called a "class" that allows us to have what we need.

We don't have a use of it, but removing this faulty
bound declaration seems practical.

--
Zhihao

--
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/a4OVg1yPc11FE0N3Bww_VmWNoDmoHN-cnx9dtcIzmuiy3Spk9Y6ZC9TYDdN18GN2b1ra0s8SBcTaITZfcsC5Yw-IJc-u0fvO4DZDfFPSj2c%3D%40miator.net.

.