------=_Part_4960_1994215863.1489896782172
Content-Type: multipart/alternative;
 boundary="----=_Part_4961_508203819.1489896782172"

------=_Part_4961_508203819.1489896782172
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, March 18, 2017 at 1:20:37 PM UTC-7, Matthew Fioravante wrote:
>
> In C++, we inherited this rule from C where primitive types like ints and=
=20
> pointers are uninitialized by default.
>
> Before getting into it, essentially what I'm suggesting is first we add a=
=20
> syntax for explicitly leaving a variable uninitialized
>
> int x =3D void; //I'm telling you x really is intended to start its life=
=20
> uninitialized
> std::cout << x << std::endl; //undefined behavior
>
> Next, we can suggest compilers warn if you don't provide an initializer=
=20
> for types that would otherwise default to be uninitialized.
>
> Note that for class types with constructors like vector, you can still go=
=20
> on with no initializer. The warning scheme is what maintains backwards=20
> compatibility.
>

What you're describing sounds good, but you've picked the wrong syntax for=
=20
it. Look at the semantics again:
- We want to add a semi-standardized diagnostic for an existing construct
- We need a way to annotate the construct in order to suppress the=20
diagnostic
- The annotation should have no effect on codegen

What kind of syntax does C++ already have for this kind of thing? Answer:=
=20
attributes.
In fact what you're proposing is basically identical to the existing C++17=
=20
attribute [[maybe_unused]], in terms of its interactions with codegen and=
=20
diagnostics.

    int x [[uninitialized]];  // yes, compiler, I know this variable is=20
uninitialized; please don't complain about it

    struct Foo {
        int m [[uninitialized]];  // yes, compiler, I know this member=20
isn't always initialized; please don't complain about it
        Foo() { }
    };

A proposal along these lines would sound good to me.
Sadly I'm not sure there's any prior art for actually giving such warnings.=
=20
Maybe in compilers that support MISRA-C++...?

=E2=80=93Arthur

--=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/90f34150-9513-4b5a-a026-2d73334ece05%40isocpp.or=
g.

------=_Part_4961_508203819.1489896782172
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, March 18, 2017 at 1:20:37 PM UTC-7, Matthew F=
ioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">In C++, we inherited this rule from C where primitive types like ints an=
d pointers are uninitialized by default.<br><br>Before getting into it, ess=
entially what I&#39;m suggesting is first we add a syntax for explicitly le=
aving a variable uninitialized<br><br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x"><code><div><span style=3D"color:#008">int</span><span style=3D"color:#00=
0"> x </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">void</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#800">//I&#=
39;m telling you x really is intended to start its life uninitialized</span=
><span style=3D"color:#000"><br>std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">cout </span><span style=3D"color:#660">&lt;&l=
t;</span><span style=3D"color:#000"> x </span><span style=3D"color:#660">&l=
t;&lt;</span><span style=3D"color:#000"> std</span><span style=3D"color:#66=
0">::</span><span style=3D"color:#000">endl</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"> </span><span style=3D"color:#800">//u=
ndefined behavior</span><span style=3D"color:#000"><br></span></div></code>=
</div><br>Next, we can suggest compilers warn if you don&#39;t provide an i=
nitializer for types that would otherwise default to be uninitialized.<br><=
br>Note that for class types with constructors like vector, you can still g=
o on with no initializer. The warning scheme is what maintains backwards co=
mpatibility.</div></blockquote><div><br></div><div>What you&#39;re describi=
ng sounds good, but you&#39;ve picked the wrong syntax for it. Look at the =
semantics again:</div><div>- We want to add a semi-standardized diagnostic =
for an existing construct</div><div>- We need a way to annotate the constru=
ct in order to suppress the diagnostic</div><div>- The annotation should ha=
ve no effect on codegen</div><div><br></div><div>What kind of syntax does C=
++ already have for this kind of thing? Answer: attributes.</div><div>In fa=
ct what you&#39;re proposing is basically identical to the existing C++17 a=
ttribute [[maybe_unused]], in terms of its interactions with codegen and di=
agnostics.</div><div><br></div><div>=C2=A0 =C2=A0 int x [[uninitialized]]; =
=C2=A0// yes, compiler, I know this variable is uninitialized; please don&#=
39;t complain about it</div><div><br></div><div>=C2=A0 =C2=A0 struct Foo {<=
/div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 int m [[uninitialized]]; =C2=A0// yes=
, compiler, I know this member isn&#39;t always initialized; please don&#39=
;t complain about it</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Foo() { }<br></d=
iv><div>=C2=A0 =C2=A0 };</div><div><br></div><div>A proposal along these li=
nes would sound good to me.</div><div>Sadly I&#39;m not sure there&#39;s an=
y prior art for actually giving such warnings. Maybe in compilers that supp=
ort MISRA-C++...?</div><div><br></div><div>=E2=80=93Arthur</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/90f34150-9513-4b5a-a026-2d73334ece05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90f34150-9513-4b5a-a026-2d73334ece05=
%40isocpp.org</a>.<br />

------=_Part_4961_508203819.1489896782172--

------=_Part_4960_1994215863.1489896782172--

.

------=_Part_3618_1594626724.1489902946942
Content-Type: multipart/alternative;
 boundary="----=_Part_3619_1060085568.1489902946942"

------=_Part_3619_1060085568.1489902946942
Content-Type: text/plain; charset=UTF-8



On Saturday, March 18, 2017 at 11:13:02 PM UTC-5, Arthur O'Dwyer wrote:
>
>
> What you're describing sounds good, but you've picked the wrong syntax for
> it. Look at the semantics again:
> - We want to add a semi-standardized diagnostic for an existing construct
> - We need a way to annotate the construct in order to suppress the
> diagnostic
> - The annotation should have no effect on codegen
>
> What kind of syntax does C++ already have for this kind of thing? Answer:
> attributes.
>

I agree that attributes were designed for this thing but that doesn't mean
you have to use an attribute. While its true = void actually does nothing
for codegen, its much shorter and less verbose and ugly than an attribute.

While the final syntax can be debated, I much prefer to write this:

int x = void;

 Instead of this

int x [[uninitialized]];

The first one is natural and pretty obvious in that it says "I'm assigning
nothing to x". The second one while readable is ugly and long.

Implementing warnings is a good way to get past some of the backward
compatible pitfalls in C++. However attribute syntax is ugly and verbose,
and I'm worried C++ of the future will be full of attributes everywhere to
suppress warnings.

People have also moaned and groaned about how things like std::vector<int>
will always zero intiailize the elements. We could think about extending
this = void concept to allowing one to create a vector<int> that starts
uninitialized. Then the syntax actually does affect code gen in some cases
and is consistent wherever its used.

--
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/eccfa49a-5316-459d-9db3-aaa40fc8667d%40isocpp.org.

------=_Part_3619_1060085568.1489902946942
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, March 18, 2017 at 11:13:02 PM UTC-5, =
Arthur O&#39;Dwyer 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"><br><div>What you&#39;re describing sounds good, but you&#39;ve=
 picked the wrong syntax for it. Look at the semantics again:</div><div>- W=
e want to add a semi-standardized diagnostic for an existing construct</div=
><div>- We need a way to annotate the construct in order to suppress the di=
agnostic</div><div>- The annotation should have no effect on codegen</div><=
div><br></div><div>What kind of syntax does C++ already have for this kind =
of thing? Answer: attributes.</div></div></blockquote><div><br>I agree that=
 attributes were designed for this thing but that doesn&#39;t mean you have=
 to use an attribute. While its true =3D void actually does nothing for cod=
egen, its much shorter and less verbose and ugly than an attribute.<br><br>=
While the final syntax can be debated, I much prefer to write this:<br><br>=
<div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-wor=
d;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>=C2=A0Instead of =
this<br><br><div style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wra=
p: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">uninitialized</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">]];</span></div=
></code></div><br>The first one is natural and pretty obvious in that it sa=
ys &quot;I&#39;m assigning nothing to x&quot;. The second one while readabl=
e is ugly and long.<br><br>Implementing warnings is a good way to get past =
some of the backward compatible pitfalls in C++. However attribute syntax i=
s ugly and verbose, and I&#39;m worried C++ of the future will be full of a=
ttributes everywhere to suppress warnings.<br><br>People have also moaned a=
nd groaned about how things like std::vector&lt;int&gt; will always zero in=
tiailize the elements. We could think about extending this =3D void concept=
 to allowing one to create a vector&lt;int&gt; that starts uninitialized. T=
hen the syntax actually does affect code gen in some cases and is consisten=
t wherever its used.<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/eccfa49a-5316-459d-9db3-aaa40fc8667d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eccfa49a-5316-459d-9db3-aaa40fc8667d=
%40isocpp.org</a>.<br />

------=_Part_3619_1060085568.1489902946942--

------=_Part_3618_1594626724.1489902946942--

.

On 2017-03-19 06:55, Matthew Fioravante wrote:
>
>
> On Saturday, March 18, 2017 at 11:13:02 PM UTC-5, Arthur O'Dwyer wrote:
>
>
>     What you're describing sounds good, but you've picked the wrong
>     syntax for it. Look at the semantics again:
>     - We want to add a semi-standardized diagnostic for an existing
>     construct
>     - We need a way to annotate the construct in order to suppress the
>     diagnostic
>     - The annotation should have no effect on codegen
>
>     What kind of syntax does C++ already have for this kind of thing?
>     Answer: attributes.
>
>
> I agree that attributes were designed for this thing but that doesn't
> mean you have to use an attribute. While its true = void actually does
> nothing for codegen, its much shorter and less verbose and ugly than an
> attribute.
>
> While the final syntax can be debated, I much prefer to write this:
>
> |
> int x =void;
> |
>
>  Instead of this
>
> |
> int x [[uninitialized]];
> |
>
> The first one is natural and pretty obvious in that it says "I'm
> assigning nothing to x". The second one while readable is ugly and long.

What's wrong with being ugly and verbose when doing unusual things? It's
not that the code is just full of uninitialized variables, right.

We already have things like reinterpret_cast that is ugly by design, in
part to make the programmer think about if this *really* is needed:
"What will the other guys say at the code review?"



     Bo Persson


--
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/oalm1i%24jle%241%40blaine.gmane.org.

.