------=_Part_9921_1634987279.1507763387252
Content-Type: multipart/alternative;
 boundary="----=_Part_9922_1600833348.1507763387252"

------=_Part_9922_1600833348.1507763387252
Content-Type: text/plain; charset="UTF-8"



I had this thought from reading one of the other threads on here:

The following code compiles by default without warning.

#include <string>

int main()
{
    std::string s;
}

This code also compiles without warning:


#include <cstdio>
#include <iostream>
struct Whatever
{
    int z;
    Whatever() { z = 0; std::cout << "Whatever!\n"; }
};
int main()
{
    Whatever x;
}

It seems constructing a named object and then not calling any methods on it
usually represents "non use" and is usually a programmer mistake.

If the compiler could diagnose this "non use", it would be useful
so programmers could clean up their code.

But as construction may serve an essential purpose, a warning on this may
be bogus. lock_guard springs to mind as an example of that.

However, I would think in the vast majority of cases, construction only is
a mistake and std::string seems like a poster child for that.

Can we improve on this situation so that the example code can be diagnosed
more trivially?

Suggestion:

Can we do something like mandate that the compiler can warn about potential
non use of an object if it is constructed but no methods on it are called
on it, unless the constructor is marked to state that construction only is
meaningfull?

i.e.:

struct Whatever
{
    int z;
    Whatever() [[construction_only_of_use]] { z = 0; std::cout <<
"Whatever!\n"; }
    // If applied to the struct then however this type is constructed,
    // it will be diagnosed as unused if no methods are called on it.
};

int main()
{
    Whatever x; // Diagnose as unused. Use [[construction_only_of_use]] to
prevent.
}

There might need more definition here as to what counts as "use" (i.e. also
don't diagnose if we take the address of the variable or whatever) but it
seems the essential idea is viable.

I think the compiler could be instructed to optimize away objects that are
constructed but "not used" by this definition though I don't imagine doing
it aggressively by default or presently, but in the future this may be more
practical.

Before that can happen I think existing code would need to be updated with
the attribute I described above. std::lock_guard would be an example of
such a class, in order that no bogus warnings are issued.

But the value is that accidental declaration and non use of std::string
would be an example of something I think this feature would catch
frequently.

This warning could be on by default once we have the tools to prevent bogus
diagnosis of unused variables. For now, by default I would expect the
compiler to be conservative about optimizing such "unused" variables. But
perhaps in the future it could be aggressive about such optimization once
the tools to find and fix our mistakes and mark our intent have been in
place for a while.

If we can already control construction only issues like I have described, I
am not aware of how.

Thoughts?

--
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/e253e302-04f0-4c18-9c0e-7b0adb8f5f26%40isocpp.org.

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

<div dir=3D"ltr"><p>I had this thought from reading one of the other thread=
s on here:</p><div><br></div><div>The following code compiles by default wi=
thout warning.</div><div><br></div><p>#include &lt;string&gt;</p><p>int mai=
n()<br>{<br>=C2=A0=C2=A0=C2=A0 std::string s;<br>}</p><div><br></div><div>T=
his code also compiles without warning:</div><p><br>#include &lt;cstdio&gt;=
<br>#include &lt;iostream&gt;</p><div>struct Whatever<br>{<br>=C2=A0=C2=A0=
=C2=A0 int z;<br>=C2=A0=C2=A0=C2=A0 Whatever() { z =3D 0; std::cout &lt;&lt=
; &quot;Whatever!\n&quot;; }<br>};</div><div>int main()<br>{<br>=C2=A0=C2=
=A0=C2=A0 Whatever x;<br>}</div><div><br></div><div>It=C2=A0seems construct=
ing a named object and then not calling any methods on it usually represent=
s &quot;non use&quot; and is usually a programmer mistake.</div><div><br>If=
=C2=A0the compiler could diagnose this &quot;non use&quot;, it would be use=
ful so=C2=A0programmers could=C2=A0clean up=C2=A0their code.</div><div><br>=
</div><div>But=C2=A0as construction may serve an essential purpose,=C2=A0a=
=C2=A0warning on this may be bogus. lock_guard springs to mind as an exampl=
e of that.</div><div><br>However, I=C2=A0would think in the vast majority o=
f cases, construction only is a mistake and std::string seems like a poster=
 child for that.</div><div><br></div><div>Can we improve on this situation =
so that the example code can be diagnosed more trivially?</div><div><br></d=
iv><div>Suggestion:</div><div><br></div><div>Can we do something like=C2=A0=
mandate that the compiler can warn about=C2=A0potential non use of an objec=
t if it is constructed but no methods on it are called on it, unless the co=
nstructor is marked to state that construction only is meaningfull?</div><d=
iv><br></div><div>i.e.:</div><div><br></div><p>struct Whatever<br>{<br>=C2=
=A0=C2=A0=C2=A0 int z;<br>=C2=A0=C2=A0=C2=A0 Whatever() [[construction_only=
_of_use]] { z =3D 0; std::cout &lt;&lt; &quot;Whatever!\n&quot;; }<br>=C2=
=A0=C2=A0=C2=A0 // If applied to the struct then however this type is const=
ructed,<br>=C2=A0=C2=A0=C2=A0 // it will be diagnosed as unused if no metho=
ds are called on it.<br>};</p><p>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 What=
ever x; // Diagnose as unused. Use [[construction_only_of_use]] to prevent.=
<br>}</p><div><br></div><div>There might need more definition here as to wh=
at counts as &quot;use&quot; (i.e. also don&#39;t diagnose if we take the a=
ddress of the variable or whatever)=C2=A0but it seems the essential idea is=
 viable.</div><div><br>I think the compiler could=C2=A0be instructed to opt=
imize away objects that are constructed but &quot;not used&quot; by this de=
finition though I don&#39;t imagine doing it aggressively by default or pre=
sently, but in the future this may be more practical.</div><div><br></div><=
div>Before that can happen I think existing code would need to be updated w=
ith the attribute I described above.=C2=A0std::lock_guard would be an examp=
le=C2=A0of such a class, in order=C2=A0that no=C2=A0bogus warnings are issu=
ed.</div><div><br>But the value is that accidental declaration and non use =
of std::string would be an example of something I think this feature would=
=C2=A0catch frequently.</div><div><br>This=C2=A0warning could be on by defa=
ult once we have the tools to prevent bogus diagnosis of unused variables.=
=C2=A0For now, by=C2=A0default I would expect the compiler to be conservati=
ve about optimizing such &quot;unused&quot; variables. But perhaps in the f=
uture it could be aggressive about such optimization once the tools to find=
 and fix our mistakes and mark=C2=A0our intent have been=C2=A0in place for =
a while.</div><div><br></div><p>If we can already control construction only=
 issues=C2=A0like I have described, I am not aware of how.</p><div><br></di=
v><div>Thoughts?<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/e253e302-04f0-4c18-9c0e-7b0adb8f5f26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e253e302-04f0-4c18-9c0e-7b0adb8f5f26=
%40isocpp.org</a>.<br />

------=_Part_9922_1600833348.1507763387252--

------=_Part_9921_1634987279.1507763387252--

.

------=_Part_2417_1220767267.1507778188290
Content-Type: multipart/alternative;
 boundary="----=_Part_2418_711415550.1507778188290"

------=_Part_2418_711415550.1507778188290
Content-Type: text/plain; charset="UTF-8"

Re-reading my previous post I feel some of it could be clearer.

What I'm suggesting is providing tools so that code like this: int main()
{ std::string s; } can generate some kind of "object 's' appears unused"
compiler warning, with no effort from the class author or user on the basis
that patterns like this usually indicate a mistake but the compiler can't
tell that unless we tell it.

The goal is to enable *the user* to find and remove such code (in this case
's') as it improves code clarity as well as code performance and C++ is
striving for both.

We can't do this already (I assume) because classes like
std::lock_guard invite a construction only pattern. So I'm suggesting
we decorate those types or their constructors to say "construction only is
ok". Once decorated, warnings of "unused" instances of those classes will
vanish.

Once the std::lock_guard type of classes are correctly identified, I expect
most of the remaining warnings will be identifying a mistake of leaving an
object constructed that they aren't using any more. Where the warning is
correct, the user will delete that code and the warning will cease because
of that.

Where the warning is not appropriate for some instance because the user
wants just construction, I'm suggesting they annotate that statement to say
that to silence the warning. I'm suggesting using the an
attribute of[[construction_only_of_use]] again for that.

The use of attributes and the exact names is not important here so much as
the idea of diagnosing errant use of constructed but otherwise unused
objects. I think most struct/class objects fit that mould so this feature
would catch a lot of mistakes.

Objects that are reported "maybe unused" will still have code generated for
them (if the compiler was going to) so the idea is that these warning are
always "safe" so can be on by default.

The main aim of this feature is to by default enable us to find code that
we don't mean to exist so that *we* can remove it from our source code
so it's clearer and faster and if we do "nothing" in response no harm is
done.

But I think this model also opens a path to enable more diagnosis and
optimization opportunities and with more chance of them being correct such
that eventually we could have an optimization that just removes any
constructed but otherwise unused objects and down the line maybe have that
on by default.

--
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/b9e0b1b8-9fa2-411a-9698-a10dd8986364%40isocpp.org.

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

<div dir=3D"ltr"><div>Re-reading my previous post I feel some of it could b=
e=C2=A0clearer.</div><div><br></div><div>What I&#39;m suggesting=C2=A0is pr=
oviding tools=C2=A0so that code=C2=A0like this:=C2=A0int main() {=C2=A0std:=
:string s; } can generate some kind of &quot;object &#39;s&#39; appears unu=
sed&quot; compiler warning, with no effort from the=C2=A0class author or us=
er on the basis that=C2=A0patterns like this=C2=A0usually=C2=A0indicate a=
=C2=A0mistake but the compiler can&#39;t tell that unless we tell it.</div>=
<div><br></div><div>The=C2=A0goal is to enable=C2=A0*the user* to find and =
remove such code=C2=A0(in this case &#39;s&#39;) as it improves code clarit=
y as well as code performance and=C2=A0C++ is striving for both.</div><div>=
<br></div><div>We can&#39;t do this already (I assume) because classes like=
 std::lock_guard=C2=A0invite a construction only pattern.=C2=A0So I&#39;m s=
uggesting we=C2=A0decorate=C2=A0those=C2=A0types or their constructors=C2=
=A0to say=C2=A0&quot;construction only is ok&quot;.=C2=A0Once decorated,=C2=
=A0warnings of &quot;unused&quot;=C2=A0instances=C2=A0of=C2=A0those classes=
 will vanish. </div><div><br></div><div>Once the std::lock_guard=C2=A0type =
of classes are correctly identified, I expect most of the remaining=C2=A0wa=
rnings will=C2=A0be identifying a=C2=A0mistake of leaving an object constru=
cted that they aren&#39;t using any more.=C2=A0Where the warning is correct=
, the user will delete that code=C2=A0and the=C2=A0warning will cease becau=
se of that.</div><div><br></div><div>Where=C2=A0the warning is not appropri=
ate=C2=A0for some=C2=A0instance=C2=A0because the user wants=C2=A0just const=
ruction, I&#39;m suggesting they=C2=A0annotate that statement to say that t=
o=C2=A0silence the warning.=C2=A0I&#39;m suggesting using=C2=A0the=C2=A0an =
attribute=C2=A0of[[construction_only_of_use]] again for that.</div><div><br=
></div><div>The use of attributes and the exact names is not important=C2=
=A0here so much as the idea=C2=A0of diagnosing=C2=A0errant use of construct=
ed but otherwise unused objects. I think most struct/class objects fit that=
 mould so this feature would catch a lot of mistakes.</div><div><br></div><=
div>Objects that are reported=C2=A0&quot;maybe unused&quot; will still have=
=C2=A0code generated for them (if=C2=A0the compiler was going to) so the id=
ea=C2=A0is that these warning=C2=A0are always &quot;safe&quot; so can be on=
 by default.</div><div><br></div><div>The main aim of this feature is=C2=A0=
to by default enable us=C2=A0to find=C2=A0code that we don&#39;t mean to ex=
ist so that *we* can remove it from our source code so=C2=A0it&#39;s cleare=
r and faster and if we do &quot;nothing&quot; in response no harm is done.<=
/div><div><br></div><div>But I think this model=C2=A0also=C2=A0opens=C2=A0a=
=C2=A0path=C2=A0to=C2=A0enable=C2=A0more diagnosis and optimization opportu=
nities=C2=A0and with=C2=A0more chance of them being correct such that event=
ually=C2=A0we could have an=C2=A0optimization that just removes any constru=
cted but otherwise unused objects and down the line maybe have that on=C2=
=A0by default.</div><div><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/b9e0b1b8-9fa2-411a-9698-a10dd8986364%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b9e0b1b8-9fa2-411a-9698-a10dd8986364=
%40isocpp.org</a>.<br />

------=_Part_2418_711415550.1507778188290--

------=_Part_2417_1220767267.1507778188290--

.

------=_Part_11093_859412656.1507823787679
Content-Type: multipart/alternative;
 boundary="----=_Part_11094_1780902450.1507823787679"

------=_Part_11094_1780902450.1507823787679
Content-Type: text/plain; charset="UTF-8"

Compilers are already smart enough to optimize away code that never
performs I/O, such as your example with std::string.
https://godbolt.org/g/3mKNwn

-Ray

--
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/3e025662-c9e5-4e62-be32-2bf67b6be143%40isocpp.org.

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

<div dir=3D"ltr">Compilers are already smart enough to optimize away code t=
hat never performs I/O, such as your example with std::string. https://godb=
olt.org/g/3mKNwn<br><br>-Ray<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/3e025662-c9e5-4e62-be32-2bf67b6be143%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3e025662-c9e5-4e62-be32-2bf67b6be143=
%40isocpp.org</a>.<br />

------=_Part_11094_1780902450.1507823787679--

------=_Part_11093_859412656.1507823787679--

.

--089e08287c4837fd0f055b5dbdcc
Content-Type: text/plain; charset="UTF-8"

I'd rather leave this "issue" alone; in systems where symmetrical behavior
is required (loading a DLL / unloading it, for example), a simple way to
automate unloading is using the destructor of a local (named) variable and
let RAII work its magic. If a compiler warns about it at high warning
levels, let it, but I'd keep the standard's text away.

2017-10-12 11:56 GMT-04:00 Ray Hamel <rayghamel@gmail.com>:

> Compilers are already smart enough to optimize away code that never
> performs I/O, such as your example with std::string.
> https://godbolt.org/g/3mKNwn
>
> -Ray
>
> --
> 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/3e025662-c9e5-4e62-
> be32-2bf67b6be143%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3e025662-c9e5-4e62-be32-2bf67b6be143%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAKiZDp3hp0_Qhcn7BeH_hp9bSmWT45WFfR2L5AxJFPCfbsXzjg%40mail.gmail.com.

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

<div dir=3D"ltr">I&#39;d rather leave this &quot;issue&quot; alone; in syst=
ems where symmetrical behavior is required (loading a DLL / unloading it, f=
or example), a simple way to automate unloading is using the destructor of =
a local (named) variable and let RAII work its magic. If a compiler warns a=
bout it at high warning levels, let it, but I&#39;d keep the standard&#39;s=
 text away. <br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2017-10-12 11:56 GMT-04:00 Ray Hamel <span dir=3D"ltr">&lt;<a href=3D"=
mailto:rayghamel@gmail.com" target=3D"_blank">rayghamel@gmail.com</a>&gt;</=
span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Compilers are alr=
eady smart enough to optimize away code that never performs I/O, such as yo=
ur example with std::string. <a href=3D"https://godbolt.org/g/3mKNwn" targe=
t=3D"_blank">https://godbolt.org/g/3mKNwn</a><br><br>-Ray<br></div><span cl=
ass=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3e025662-c9e5-4e62-be32-2bf67b6be143%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3e02=
5662-c9e5-4e62-<wbr>be32-2bf67b6be143%40isocpp.org</a><wbr>.<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/CAKiZDp3hp0_Qhcn7BeH_hp9bSmWT45WFfR2L=
5AxJFPCfbsXzjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3hp0_Qhcn7=
BeH_hp9bSmWT45WFfR2L5AxJFPCfbsXzjg%40mail.gmail.com</a>.<br />

--089e08287c4837fd0f055b5dbdcc--

.

On 2017-10-11 19:09, gmisocpp@gmail.com wrote:
> It seems constructing a named object and then not calling any methods on it
> usually represents "non use" and is usually a programmer mistake.
>
> If the compiler could diagnose this "non use", it would be useful
> so programmers could clean up their code.
>
> But as construction may serve an essential purpose, a warning on this may
> be bogus. lock_guard springs to mind as an example of that.

I've had this discussion before. Right around when [[nodiscard]] was
being standardized IIRC, I tried to argue that it is the wrong
attribute; what we really need is "this object must not be immediately
destroyed" and "the user must *do something* with this object".

> Can we do something like mandate that the compiler can warn about potential
> non use of an object if it is constructed but no methods on it are called
> on it, unless the constructor is marked to state that construction only is
> meaningfull?
> [...]
> There might need more definition here as to what counts as "use" (i.e. also
> don't diagnose if we take the address of the variable or whatever) but it
> seems the essential idea is viable.

Er... well... as I recall, exactly that was the sticking problem in the
earlier conversation.

I suspect that the correct answer probably amounts to "a branch in the
code depended on the value of at least one member in <object-specific
set of members>". (IOW, sort of a converse of valgrind's "conditional
expression depends on value of uninitialized bytes".) That's hard to
specify. And it's worse when you only need to care #ifdef _DEBUG.

....of course, that's also why we have [[maybe_unused]]...

--
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/f6996a18-db4c-b57c-77ea-7119a3e5145d%40gmail.com.

.

--001a11449b74720cd5055b5e685e
Content-Type: text/plain; charset="UTF-8"

My 'proposal draft' for unnamed variables would express this intent, of
having deliberately created an object with automatic lifetime, so the sole
purpose of construction and destruction, properly.
See https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md




On 12 October 2017 at 20:42, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2017-10-11 19:09, gmisocpp@gmail.com wrote:
> > It seems constructing a named object and then not calling any methods on
> it
> > usually represents "non use" and is usually a programmer mistake.
> >
> > If the compiler could diagnose this "non use", it would be useful
> > so programmers could clean up their code.
> >
> > But as construction may serve an essential purpose, a warning on this may
> > be bogus. lock_guard springs to mind as an example of that.
>
> I've had this discussion before. Right around when [[nodiscard]] was
> being standardized IIRC, I tried to argue that it is the wrong
> attribute; what we really need is "this object must not be immediately
> destroyed" and "the user must *do something* with this object".
>
> > Can we do something like mandate that the compiler can warn about
> potential
> > non use of an object if it is constructed but no methods on it are called
> > on it, unless the constructor is marked to state that construction only
> is
> > meaningfull?
> > [...]
> > There might need more definition here as to what counts as "use" (i.e.
> also
> > don't diagnose if we take the address of the variable or whatever) but it
> > seems the essential idea is viable.
>
> Er... well... as I recall, exactly that was the sticking problem in the
> earlier conversation.
>
> I suspect that the correct answer probably amounts to "a branch in the
> code depended on the value of at least one member in <object-specific
> set of members>". (IOW, sort of a converse of valgrind's "conditional
> expression depends on value of uninitialized bytes".) That's hard to
> specify. And it's worse when you only need to care #ifdef _DEBUG.
>
> ...of course, that's also why we have [[maybe_unused]]...
>
> --
> 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/f6996a18-db4c-b57c-
> 77ea-7119a3e5145d%40gmail.com.
>



--
Met vriendelijke groeten,

Jan Wilmans

--
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/CADtNNhgrpo2f9L4T-51dFfQbzQmqqEYVoOGgKY1RdFgRZQ%3D7Cw%40mail.gmail.com.

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

<div dir=3D"ltr">My &#39;proposal draft&#39; for unnamed variables would ex=
press this intent, of having deliberately created an object with automatic =
lifetime, so the sole purpose of construction and destruction, properly.<di=
v>See=C2=A0<a href=3D"https://github.com/janwilmans/janwilmans.github.io/bl=
ob/master/auto.md">https://github.com/janwilmans/janwilmans.github.io/blob/=
master/auto.md</a></div><div><br><div><br></div><div><br></div></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 12 October 201=
7 at 20:42, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlk=
e.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2017-10-11 1=
9:09, <a href=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a> wrote:<b=
r>
&gt; It seems constructing a named object and then not calling any methods =
on it<br>
&gt; usually represents &quot;non use&quot; and is usually a programmer mis=
take.<br>
&gt;<br>
&gt; If the compiler could diagnose this &quot;non use&quot;, it would be u=
seful<br>
&gt; so programmers could clean up their code.<br>
&gt;<br>
&gt; But as construction may serve an essential purpose, a warning on this =
may<br>
&gt; be bogus. lock_guard springs to mind as an example of that.<br>
<br>
</span>I&#39;ve had this discussion before. Right around when [[nodiscard]]=
 was<br>
being standardized IIRC, I tried to argue that it is the wrong<br>
attribute; what we really need is &quot;this object must not be immediately=
<br>
destroyed&quot; and &quot;the user must *do something* with this object&quo=
t;.<br>
<span class=3D""><br>
&gt; Can we do something like mandate that the compiler can warn about pote=
ntial<br>
&gt; non use of an object if it is constructed but no methods on it are cal=
led<br>
&gt; on it, unless the constructor is marked to state that construction onl=
y is<br>
&gt; meaningfull?<br>
</span>&gt; [...]<br>
<span class=3D"">&gt; There might need more definition here as to what coun=
ts as &quot;use&quot; (i.e. also<br>
&gt; don&#39;t diagnose if we take the address of the variable or whatever)=
 but it<br>
&gt; seems the essential idea is viable.<br>
<br>
</span>Er... well... as I recall, exactly that was the sticking problem in =
the<br>
earlier conversation.<br>
<br>
I suspect that the correct answer probably amounts to &quot;a branch in the=
<br>
code depended on the value of at least one member in &lt;object-specific<br=
>
set of members&gt;&quot;. (IOW, sort of a converse of valgrind&#39;s &quot;=
conditional<br>
expression depends on value of uninitialized bytes&quot;.) That&#39;s hard =
to<br>
specify. And it&#39;s worse when you only need to care #ifdef _DEBUG.<br>
<br>
....of course, that&#39;s also why we have [[maybe_unused]]...<br>
<br>
--<br>
Matthew<br>
<span class=3D""><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/f6996a18-db4c-b57c-77ea-7119a3=
e5145d%40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.goo=
gle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f6996a18-db4c-b57c-<wb=
r>77ea-7119a3e5145d%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Met vriendelijke gr=
oeten,<br><br>Jan Wilmans<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/CADtNNhgrpo2f9L4T-51dFfQbzQmqqEYVoOGg=
KY1RdFgRZQ%3D7Cw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhgrpo2f9L=
4T-51dFfQbzQmqqEYVoOGgKY1RdFgRZQ%3D7Cw%40mail.gmail.com</a>.<br />

--001a11449b74720cd5055b5e685e--

.

------=_Part_11802_413467186.1507839800580
Content-Type: multipart/alternative;
 boundary="----=_Part_11803_900885097.1507839800581"

------=_Part_11803_900885097.1507839800581
Content-Type: text/plain; charset="UTF-8"


>
>
> Er... well... as I recall, exactly that was the sticking problem in the
> earlier conversation.
>
> I suspect that the correct answer probably amounts to "a branch in the
> code depended on the value of at least one member in <object-specific
> set of members>". (IOW, sort of a converse of valgrind's "conditional
> expression depends on value of uninitialized bytes".) That's hard to
> specify. And it's worse when you only need to care #ifdef _DEBUG.
>
>
>
I expect to find a sticking point in this area again and it may well be
those people arguing for no change are right.

But right now, my non expert view is that the compiler and only spot use,
but what actually counts as use and valid use?

In my simple tests, MSVC (and gcc) did not warn that the string variable in
my example was "unused". *The question is why?*

And remember my goal is code clarity more than performance, because my aim
is to warn that the string is unused so I as a programmer can remove the
bogus variable from my program and improve clarity.

Optimization is secondary to this i.e. if the compiler optimized the code
away, I care less about that fact, other than to note that if it was able
to, why was it not able to warn me so I can clean up my source code not
just have by executable cleaner?

I'm not sure myself if optimizing that results in the whole code being
removed implies the compiler noticed in a more straight forward way that
the object was unused so it can warn. It might just have happened that
various passes of optimization picked away at it code to get the result so
that's why it was unable to warn. So the reason why there was no warning
for my example is of interest to me.

But my thinking at the moment is the compiler cannot get us where we want
because it can't know what counts as use so we need to tell it with
attributes or some such thing.

You mentioned  "branch in the
code depended on the value of at least one member in <object-specific
set of members>" but is that enough, because my thought are:

But whose branches should the compiler be looking at?
Branches in the constructor itself on it's own members happen. We are
probably not getting a warning for my example because the compiler is
counting the object's own use of itself in the constructor as use.

To my mind, in any case, constructors will do useful things that may or may
not be considered 'use' from a technical point.

But regardless, it is a design issue if "construction only" is desirable or
not. I don't see how the compiler can know.

For example, if I start building a house, I can lay the foundations. (Call
that construction for my purposes), and then never go on to build the
house. In the real world that's probably means someone has forgotten to
finish the job, but technically the land has been used.

Another example, in my app I might declare a dialog box class instance, but
if nowhere in my code exists some kind of Show() call, the chances are I'm
not using the dialog box any more but I've just forgotten to remove it from
my code.

If the compiler doesn't choose to warn me, then that dialog or string
declaration is stuck in my source code, even if it is optimized away at
runtime. But how can it know what to do, because in the case of lock_guard,
I want this result. I'm not sure how the compiler can spot the difference
unless I tell it because it seems it's a design thing?

In summary, the answers to these questions might help my thinking at least
on this:
1. why is the compiler not warning me my string is 'unused' in my simple
example code.
2. is it because it's seeing the strings own use in it's constructor as
definitive 'use' so not warning?
3. If this is why, looking at outside use probably isn't enough,
because things like lock_guard have no outside use by design. So how is it
going to get the answer I want if we don't help it?

That's a long reply, but I hope that relates to your branches comment in
the way you were thinking.

Thanks

--
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/ed8e9f0c-5182-42b0-ab86-e62538d5b074%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><br>Er... well... as I recall=
, exactly that was the sticking problem in the
<br>earlier conversation.
<br>
<br>I suspect that the correct answer probably amounts to &quot;a branch in=
 the
<br>code depended on the value of at least one member in &lt;object-specifi=
c
<br>set of members&gt;&quot;. (IOW, sort of a converse of valgrind&#39;s &q=
uot;conditional
<br>expression depends on value of uninitialized bytes&quot;.) That&#39;s h=
ard to
<br>specify. And it&#39;s worse when you only need to care #ifdef _DEBUG.
<br>
<br><br></blockquote><div><br></div><div>I expect to find a sticking point =
in this area again and it may well be those people arguing for no change ar=
e right.</div><div><br></div><div>But right now, my non expert view is that=
 the compiler and only spot use, but what actually counts as use and valid =
use?</div><div><br></div><div>In my simple tests, MSVC (and gcc) did not wa=
rn that the string variable in my example was &quot;unused&quot;. *The ques=
tion is why?*</div><div><br></div><div>And remember my goal is code clarity=
 more than performance, because my aim is to warn that the string is unused=
 so I as a programmer can remove the bogus variable from my program and imp=
rove clarity.</div><div><br></div><div>Optimization is secondary to this i.=
e. if the compiler optimized the code away, I care less about that fact, ot=
her than to note that if it was able to, why was it not able to warn me so =
I can clean up my source code not just have by executable cleaner?</div><di=
v><br></div><div>I&#39;m not sure=C2=A0myself if optimizing that results in=
 the=C2=A0whole code being removed=C2=A0implies=C2=A0the compiler noticed i=
n a more=C2=A0straight forward=C2=A0way that the object was unused so it ca=
n warn. It might just have happened=C2=A0that various passes of optimizatio=
n picked away at it code to get the result so that&#39;s why it was unable =
to warn. So the reason why there was no warning for my example is of intere=
st to me.</div><div><br></div><div>But my thinking at the moment is the com=
piler cannot get us where we want because it can&#39;t know what counts as=
=C2=A0use so we need to tell it with attributes or some such thing.</div><d=
iv><br></div><div>You mentioned=C2=A0 &quot;branch in the <br>code depended=
 on the value of at least one member in &lt;object-specific <br>set of memb=
ers&gt;&quot; but is that enough, because my thought are:</div><div><br></d=
iv><div>But=C2=A0whose branches should the compiler be looking at?</div><di=
v>Branches in the constructor itself=C2=A0on it&#39;s own members happen. W=
e=C2=A0are probably not getting a warning for my example because the compil=
er is counting the object&#39;s own use of itself in the constructor as use=
..</div><div><br></div><div>To my mind, in any case, constructors will do us=
eful things that may or may not be considered &#39;use&#39; from a technica=
l point.</div><div><br></div><div>But regardless, it=C2=A0is a design issue=
=C2=A0if=C2=A0&quot;construction only&quot;=C2=A0is desirable or not. I don=
&#39;t see=C2=A0how the=C2=A0compiler can know.</div><div><br></div><div>Fo=
r example, if I start building a house, I can lay the foundations. (Call th=
at construction for my purposes), and then never go on to build the house. =
In the real world that&#39;s probably means someone has forgotten to finish=
 the job, but technically the land has been used.</div><div><br></div><div>=
Another example, in my app=C2=A0I might=C2=A0declare a=C2=A0dialog box=C2=
=A0class instance, but if nowhere in my code=C2=A0exists some kind of Show(=
) call, the chances are I&#39;m not using the dialog box any more but I&#39=
;ve just forgotten to remove it from my code.</div><div>=C2=A0</div><div>If=
 the compiler doesn&#39;t choose=C2=A0to warn me, then that dialog or strin=
g declaration is stuck in my source code, even if it is optimized away at r=
untime. But how can it know what to do, because in the case of lock_guard, =
I want this result. I&#39;m not sure how the compiler can spot the differen=
ce unless I tell it because it seems it&#39;s a design thing?</div><div><br=
></div><div>In summary, the answers to these questions might help my thinki=
ng at least on this:</div><div>1. why is the compiler not warning me my=C2=
=A0string is &#39;unused&#39; in my simple example code.</div><div>2. is it=
 because it&#39;s seeing the strings own use in it&#39;s constructor=C2=A0a=
s definitive &#39;use&#39;=C2=A0so not warning?</div><div>3.=C2=A0If this i=
s why, looking at outside use probably isn&#39;t enough, because=C2=A0thing=
s like lock_guard=C2=A0have no outside use by design. So how is it going to=
 get the answer I want if we don&#39;t help it?</div><div><br></div><div>Th=
at&#39;s a long reply, but I hope that=C2=A0relates to your branches commen=
t in the way you were thinking.</div><div><br></div><div>Thanks</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/ed8e9f0c-5182-42b0-ab86-e62538d5b074%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ed8e9f0c-5182-42b0-ab86-e62538d5b074=
%40isocpp.org</a>.<br />

------=_Part_11803_900885097.1507839800581--

------=_Part_11802_413467186.1507839800580--

.

------=_Part_11260_250571963.1507839952823
Content-Type: multipart/alternative;
 boundary="----=_Part_11261_1320460978.1507839952823"

------=_Part_11261_1320460978.1507839952823
Content-Type: text/plain; charset="UTF-8"


Hi Jan

As best I can tell, your proposal is solving a different problem? See my
reply to Matthew that might reveal to you if this is a true statement or
not.

On Friday, October 13, 2017 at 8:18:42 AM UTC+13, Jan Wilmans wrote:

> My 'proposal draft' for unnamed variables would express this intent, of
> having deliberately created an object with automatic lifetime, so the sole
> purpose of construction and destruction, properly.
> See https://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md
>
>
>
>
> On 12 October 2017 at 20:42, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
>
>> On 2017-10-11 19:09, gmis...@gmail.com <javascript:> wrote:
>> > It seems constructing a named object and then not calling any methods
>> on it
>> > usually represents "non use" and is usually a programmer mistake.
>> >
>> > If the compiler could diagnose this "non use", it would be useful
>> > so programmers could clean up their code.
>> >
>> > But as construction may serve an essential purpose, a warning on this
>> may
>> > be bogus. lock_guard springs to mind as an example of that.
>>
>> I've had this discussion before. Right around when [[nodiscard]] was
>> being standardized IIRC, I tried to argue that it is the wrong
>> attribute; what we really need is "this object must not be immediately
>> destroyed" and "the user must *do something* with this object".
>>
>> > Can we do something like mandate that the compiler can warn about
>> potential
>> > non use of an object if it is constructed but no methods on it are
>> called
>> > on it, unless the constructor is marked to state that construction only
>> is
>> > meaningfull?
>> > [...]
>> > There might need more definition here as to what counts as "use" (i.e.
>> also
>> > don't diagnose if we take the address of the variable or whatever) but
>> it
>> > seems the essential idea is viable.
>>
>> Er... well... as I recall, exactly that was the sticking problem in the
>> earlier conversation.
>>
>> I suspect that the correct answer probably amounts to "a branch in the
>> code depended on the value of at least one member in <object-specific
>> set of members>". (IOW, sort of a converse of valgrind's "conditional
>> expression depends on value of uninitialized bytes".) That's hard to
>> specify. And it's worse when you only need to care #ifdef _DEBUG.
>>
>> ...of course, that's also why we have [[maybe_unused]]...
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6996a18-db4c-b57c-77ea-7119a3e5145d%40gmail.com
>> .
>>
>
>
>
> --
> Met vriendelijke groeten,
>
> Jan Wilmans
>

--
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/e9b74fe5-56b6-4c14-a9ee-bee4fa77dd13%40isocpp.org.

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

<div dir=3D"ltr"><div><br>Hi Jan</div><div><br></div><div>As best I can tel=
l, your proposal is solving a different problem? See my reply to Matthew th=
at might reveal to you if this is a true statement or not.</div><div><br>On=
 Friday, October 13, 2017 at 8:18:42 AM UTC+13, Jan Wilmans wrote:</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr">My &#39;proposal draft&#39; for =
unnamed variables would express this intent, of having deliberately created=
 an object with automatic lifetime, so the sole purpose of construction and=
 destruction, properly.<div>See=C2=A0<a onmousedown=3D"this.href=3D&#39;htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjanwilmans%2Fjanwil=
mans.github.io%2Fblob%2Fmaster%2Fauto.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNE8u5Vu53M0-hUwE7xaGzq-9sNBUw&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjanwilma=
ns%2Fjanwilmans.github.io%2Fblob%2Fmaster%2Fauto.md\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNE8u5Vu53M0-hUwE7xaGzq-9sNBUw&#39;;return true;" href=3D"ht=
tps://github.com/janwilmans/janwilmans.github.io/blob/master/auto.md" targe=
t=3D"_blank" rel=3D"nofollow">https://github.com/<wbr>janwilmans/janwilmans=
..github.<wbr>io/blob/master/auto.md</a></div><div><br><div><br></div><div><=
br></div></div></div><div><br><div class=3D"gmail_quote">On 12 October 2017=
 at 20:42, Matthew Woehlke <span dir=3D"ltr">&lt;<a onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofol=
low" gdf-obfuscated-mailto=3D"-Muyl4SCAAAJ">mwoehlk...@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><span>On 2017-10-11 19:09, <a o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"-Muyl4SCAAAJ">gmis...=
@gmail.com</a> wrote:<br>
&gt; It seems constructing a named object and then not calling any methods =
on it<br>
&gt; usually represents &quot;non use&quot; and is usually a programmer mis=
take.<br>
&gt;<br>
&gt; If the compiler could diagnose this &quot;non use&quot;, it would be u=
seful<br>
&gt; so programmers could clean up their code.<br>
&gt;<br>
&gt; But as construction may serve an essential purpose, a warning on this =
may<br>
&gt; be bogus. lock_guard springs to mind as an example of that.<br>
<br>
</span>I&#39;ve had this discussion before. Right around when [[nodiscard]]=
 was<br>
being standardized IIRC, I tried to argue that it is the wrong<br>
attribute; what we really need is &quot;this object must not be immediately=
<br>
destroyed&quot; and &quot;the user must *do something* with this object&quo=
t;.<br>
<span><br>
&gt; Can we do something like mandate that the compiler can warn about pote=
ntial<br>
&gt; non use of an object if it is constructed but no methods on it are cal=
led<br>
&gt; on it, unless the constructor is marked to state that construction onl=
y is<br>
&gt; meaningfull?<br>
</span>&gt; [...]<br>
<span>&gt; There might need more definition here as to what counts as &quot=
;use&quot; (i.e. also<br>
&gt; don&#39;t diagnose if we take the address of the variable or whatever)=
 but it<br>
&gt; seems the essential idea is viable.<br>
<br>
</span>Er... well... as I recall, exactly that was the sticking problem in =
the<br>
earlier conversation.<br>
<br>
I suspect that the correct answer probably amounts to &quot;a branch in the=
<br>
code depended on the value of at least one member in &lt;object-specific<br=
>
set of members&gt;&quot;. (IOW, sort of a converse of valgrind&#39;s &quot;=
conditional<br>
expression depends on value of uninitialized bytes&quot;.) That&#39;s hard =
to<br>
specify. And it&#39;s worse when you only need to care #ifdef _DEBUG.<br>
<br>
....of course, that&#39;s also why we have [[maybe_unused]]...<br>
<br>
--<br>
Matthew<br>
<span><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 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"-Muyl4SCAAA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"-Muyl4SCAAAJ">std-pr...@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a onmousedown=3D"this.href=
=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6996a=
18-db4c-b57c-77ea-7119a3e5145d%40gmail.com&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/f6996a18-db4c-b57c-77ea-7119a3e5145d%40gmail.com&#39;;return true;" href=
=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6996a18-d=
b4c-b57c-77ea-7119a3e5145d%40gmail.com" target=3D"_blank" rel=3D"nofollow">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/f699=
6a18-db4c-b57c-<wbr>77ea-7119a3e5145d%40gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div>Met vri=
endelijke groeten,<br><br>Jan Wilmans<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/e9b74fe5-56b6-4c14-a9ee-bee4fa77dd13%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e9b74fe5-56b6-4c14-a9ee-bee4fa77dd13=
%40isocpp.org</a>.<br />

------=_Part_11261_1320460978.1507839952823--

------=_Part_11260_250571963.1507839952823--

.

------=_Part_9166_1094506282.1507840030346
Content-Type: multipart/alternative;
 boundary="----=_Part_9167_2047291047.1507840030347"

------=_Part_9167_2047291047.1507840030347
Content-Type: text/plain; charset="UTF-8"

See my reply to Matthew. But I'm not so much interested in are they smart
enough to optimize it away, but why aren't they smart enough to tell me so
I can optimize it away.

On Friday, October 13, 2017 at 4:56:27 AM UTC+13, Ray Hamel wrote:
>
> Compilers are already smart enough to optimize away code that never
> performs I/O, such as your example with std::string.
> https://godbolt.org/g/3mKNwn
>
> -Ray
>

--
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/9428ea6b-60e3-4ab4-91a4-0e3995132cb6%40isocpp.org.

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

<div dir=3D"ltr">See my reply to Matthew. But I&#39;m not so much intereste=
d in are they smart enough to optimize it away, but why aren&#39;t they sma=
rt enough to tell me so I can optimize it away.<br><br>On Friday, October 1=
3, 2017 at 4:56:27 AM UTC+13, Ray Hamel wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr">Compilers are already smart enough to optimize away code t=
hat never performs I/O, such as your example with std::string. <a onmousedo=
wn=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbol=
t.org%2Fg%2F3mKNwn\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFbe3mZPHEH8TmqwC=
Zu8miEfhDByQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2F3mKNwn\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNFbe3mZPHEH8TmqwCZu8miEfhDByQ&#39;;return true;" href=
=3D"https://godbolt.org/g/3mKNwn" target=3D"_blank" rel=3D"nofollow">https:=
//godbolt.org/g/3mKNwn</a><br><br>-Ray<br></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/9428ea6b-60e3-4ab4-91a4-0e3995132cb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9428ea6b-60e3-4ab4-91a4-0e3995132cb6=
%40isocpp.org</a>.<br />

------=_Part_9167_2047291047.1507840030347--

------=_Part_9166_1094506282.1507840030346--

.

------=_Part_11672_657809496.1507840963544
Content-Type: multipart/alternative;
 boundary="----=_Part_11673_113133363.1507840963544"

------=_Part_11673_113133363.1507840963544
Content-Type: text/plain; charset="UTF-8"



On Friday, October 13, 2017 at 7:30:53 AM UTC+13, Patrice Roy wrote:
>
> I'd rather leave this "issue" alone; in systems where symmetrical behavior
> is required (loading a DLL / unloading it, for example), a simple way to
> automate unloading is using the destructor of a local (named) variable and
> let RAII work its magic. If a compiler warns about it at high warning
> levels, let it, but I'd keep the standard's text away.
>

In my suggested idea, your use case would be fine, except the compiler will
warn you if that's what you meant and force you to use an attribute to
state that to get rid of the warning. Since you can put the attribute at
the class level, the author is making it clear this is a design issue, so
the users of the class need do nothing. This sounds an exact fit for your
use case.

Your message suggests your concern is mainly about optimizing though. Note
my proposal does not suggest affecting any optimization by default, so your
code is safe regardless of any warning that might be issued.

--
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/90143380-0c2b-476a-8ef9-91713ab37517%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, October 13, 2017 at 7:30:53 AM UTC+13, =
Patrice Roy wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I&#39;d rat=
her leave this &quot;issue&quot; alone; in systems where symmetrical behavi=
or is required (loading a DLL / unloading it, for example), a simple way to=
 automate unloading is using the destructor of a local (named) variable and=
 let RAII work its magic. If a compiler warns about it at high warning leve=
ls, let it, but I&#39;d keep the standard&#39;s text away. <br></div></bloc=
kquote><div><br></div><div>In my suggested idea, your use case would be fin=
e, except the compiler will warn you if that&#39;s what you meant and force=
 you to use an attribute to state that to get rid of the warning. Since you=
 can put the attribute at the class level, the author is making it clear th=
is is a design issue, so the users of the class need do nothing. This sound=
s an exact fit=C2=A0for your use case.</div><div><br></div><div>Your messag=
e suggests your concern is mainly about optimizing though. Note my proposal=
 does not suggest affecting any optimization by default, so your code is sa=
fe regardless of any warning that might be issued.</div><div><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/90143380-0c2b-476a-8ef9-91713ab37517%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90143380-0c2b-476a-8ef9-91713ab37517=
%40isocpp.org</a>.<br />

------=_Part_11673_113133363.1507840963544--

------=_Part_11672_657809496.1507840963544--

.

On 2017-10-12 16:23, gmisocpp@gmail.com wrote:
> In my simple tests, MSVC (and gcc) did not warn that the string variable in
> my example was "unused". *The question is why?*

....because it has a non-trivial ctor/dtor, which *may* be all you cared
about. Current compilers are not smart enough to distinguish between
such reasonable uses (e.g. if you'd used a lock_guard, it would be okay
that you didn't do anything else with it) and when you should have done
something more to "use" the object, nor does there exist a way to tell
the compiler which case is correct for the type. Thus, they err on not
spamming you with false positives.

> But regardless, it is a design issue if "construction only" is desirable or
> not. I don't see how the compiler can know.

We would need an attribute or something. Without that, the compiler
"must" assume that it is okay to merely construct and destroy the
object. (When I say "must"... it *could* make the opposite assumption,
but this would produce false positives, and vendors have historically
chosen to warn too little rather than too much. "Must" implies the
assumption that this choice will remain unchanged.)

--
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/01889e44-d529-1852-b0a0-a69484b5783f%40gmail.com.

.

------=_Part_11751_938845601.1507842913937
Content-Type: multipart/alternative;
 boundary="----=_Part_11752_844492671.1507842913937"

------=_Part_11752_844492671.1507842913937
Content-Type: text/plain; charset="UTF-8"


>
>
>
> We would need an attribute or something. Without that, the compiler
> "must" assume that it is okay to merely construct and destroy the
> object. (When I say "must"... it *could* make the opposite assumption,
> but this would produce false positives, and vendors have historically
> chosen to warn too little rather than too much. "Must" implies the
> assumption that this choice will remain unchanged.)
>
> --
> Matthew
>

Well that's what my suggestion calls for. So it sounds then like we are
agreeing?

--
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/a24104df-4d12-4925-b3ba-be08ecc014cc%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><br>
<br>We would need an attribute or something. Without that, the compiler
<br>&quot;must&quot; assume that it is okay to merely construct and destroy=
 the
<br>object. (When I say &quot;must&quot;... it *could* make the opposite as=
sumption,
<br>but this would produce false positives, and vendors have historically
<br>chosen to warn too little rather than too much. &quot;Must&quot; implie=
s the
<br>assumption that this choice will remain unchanged.)
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div>Well that&#39;s what my suggestion cal=
ls for. So it sounds then like we are agreeing?</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/a24104df-4d12-4925-b3ba-be08ecc014cc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a24104df-4d12-4925-b3ba-be08ecc014cc=
%40isocpp.org</a>.<br />

------=_Part_11752_844492671.1507842913937--

------=_Part_11751_938845601.1507842913937--

.

On 2017-10-12 17:15, gmisocpp@gmail.com wrote:
> On 2017-10-12 16:23, gmisocpp@gmail.com wrote:
>> We would need an attribute or something. Without that, the compiler
>> "must" assume that it is okay to merely construct and destroy the
>> object. (When I say "must"... it *could* make the opposite assumption,
>> but this would produce false positives, and vendors have historically
>> chosen to warn too little rather than too much. "Must" implies the
>> assumption that this choice will remain unchanged.)
>
> Well that's what my suggestion calls for. So it sounds then like we are
> agreeing?

We agree close enough... the devil is in the details. It's specifying
"how" this feature works that has historically prevented any such
proposal from moving forward.

I suppose you could propose a new attribute that says "it's okay to
construct this object and do nothing else with it" (I'd go that way
because those are less common), with the obvious intention being that
compilers "ought to" complain if you construct an object of some other
type and then don't use it. This could be combined with [[nodiscard]] to
say that "you need to do something with this, but just sticking it in a
named variable is sufficient".

That *might* work. Or... it might not. If not, it will probably be
because there is no agreed-upon definition of what constitutes "using
the object". That's been the sticking point, historically.

--
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/90d0428b-f5a1-3749-b9cd-b0cbeac5f422%40gmail.com.

.

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

On Thu, Oct 12, 2017 at 4:15 PM, <gmisocpp@gmail.com> wrote:

>
>>
>> We would need an attribute or something. Without that, the compiler
>> "must" assume that it is okay to merely construct and destroy the
>> object. (When I say "must"... it *could* make the opposite assumption,
>> but this would produce false positives, and vendors have historically
>> chosen to warn too little rather than too much. "Must" implies the
>> assumption that this choice will remain unchanged.)
>>
>> --
>> Matthew
>>
>
> Well that's what my suggestion calls for. So it sounds then like we are
> agreeing?
>

You want opt-out, which will generate far too many false positives on
existing, working code.  For many businesses, changing existing, working
code has a very non-trivial cost.

If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover it?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BM-uhn0%3DbC%2Bj2eThjEGj2E%2B67seko0OxeEzRr%2BD%3DfaCmw%40mail.gmail.com.

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

<div dir=3D"ltr">On Thu, Oct 12, 2017 at 4:15 PM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1e=
x;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-styl=
e:solid"><br>
<br>We would need an attribute or something. Without that, the compiler
<br>&quot;must&quot; assume that it is okay to merely construct and destroy=
 the
<br>object. (When I say &quot;must&quot;... it *could* make the opposite as=
sumption,
<br>but this would produce false positives, and vendors have historically
<br>chosen to warn too little rather than too much. &quot;Must&quot; implie=
s the
<br>assumption that this choice will remain unchanged.)
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div></span><div>Well that&#39;s what my suggest=
ion calls for. So it sounds then like we are agreeing?</div></div></blockqu=
ote><div><br></div><div>You want opt-out, which will generate far too many =
false positives on existing, working code.=C2=A0 For many businesses, chang=
ing existing, working code has a very non-trivial cost.</div><div><br></div=
><div>If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cove=
r it?</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gm=
ail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quo=
t;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</d=
iv></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/CAGg_6%2BM-uhn0%3DbC%2Bj2eThjEGj2E%2B=
67seko0OxeEzRr%2BD%3DfaCmw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAG=
g_6%2BM-uhn0%3DbC%2Bj2eThjEGj2E%2B67seko0OxeEzRr%2BD%3DfaCmw%40mail.gmail.c=
om</a>.<br />

--f403045c97c2380798055b606448--

.

------=_Part_11772_636698548.1507844812690
Content-Type: multipart/alternative;
 boundary="----=_Part_11773_855017627.1507844812690"

------=_Part_11773_855017627.1507844812690
Content-Type: text/plain; charset="UTF-8"

What I was suggesting is that by introducing a syntax to explicitly make
something unnamed, the compiler would then be free to emit warnings for all
other cases where an object is not referenced after construction, without
needed to evaluate whether the constructor/destruction has side-effects or
not.

This is what you wanted right?
On the other hand, I don't really see the value in putting that specific
warning in the standard itself, but any compiler would be free do to do it
and it would be easier to implement.

--
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/f50db722-7b91-4218-92e9-43b90f51e88a%40isocpp.org.

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

<div dir=3D"ltr">What I was suggesting is that by introducing a syntax to e=
xplicitly make something unnamed, the compiler would then be free to emit w=
arnings for all other cases where an object is not referenced after constru=
ction, without needed to evaluate whether the constructor/destruction has s=
ide-effects or not.<div><br></div><div>This is what you wanted right?</div>=
<div>On the other hand, I don&#39;t really see the value in putting that sp=
ecific warning in the standard itself, but any compiler would be free do to=
 do it and it would be easier to implement.<br><div><br></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/f50db722-7b91-4218-92e9-43b90f51e88a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f50db722-7b91-4218-92e9-43b90f51e88a=
%40isocpp.org</a>.<br />

------=_Part_11773_855017627.1507844812690--

------=_Part_11772_636698548.1507844812690--

.

------=_Part_1492_68083022.1507845247699
Content-Type: multipart/alternative;
 boundary="----=_Part_1493_144235260.1507845247699"

------=_Part_1493_144235260.1507845247699
Content-Type: text/plain; charset="UTF-8"


>
>
> If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover it?
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>
>  +1-847-691-1404
>

Making it opt-in defeats the point, right? because then existing code would
still be hit with lost of warnings, unless the warning would be off by
default, was that would you ment?

--
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/4eecbd79-425b-4eb8-8af0-2323befcbacd%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div><br></div><div>If it were opt-in, =
do [[maybe_unused]] and [[nodiscard]] already cover it?</div></div>-- <br><=
div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot;=
 Liber=C2=A0 &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"EPNjp0OKAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">ne...@eviloverlord.com</a><wbr>&gt; =C2=A0+1-847-691-140=
4</div></div></div></div></div></div></div></blockquote><div><br></div><div=
>Making it opt-in defeats the point, right? because then existing code woul=
d still be hit with lost of warnings, unless the warning would be off by de=
fault, was that would you ment?</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/4eecbd79-425b-4eb8-8af0-2323befcbacd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4eecbd79-425b-4eb8-8af0-2323befcbacd=
%40isocpp.org</a>.<br />

------=_Part_1493_144235260.1507845247699--

------=_Part_1492_68083022.1507845247699--

.

------=_Part_11835_1428870880.1507845338252
Content-Type: multipart/alternative;
 boundary="----=_Part_11836_822240895.1507845338252"

------=_Part_11836_822240895.1507845338252
Content-Type: text/plain; charset="UTF-8"

I think in case of a default-off warning the  [[maybe_unused]] attribute
could provide the same information as making it unnamed.

--
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/107ecab4-afa7-4ca7-b513-94538cadd52d%40isocpp.org.

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

<div dir=3D"ltr">I think in case of a default-off warning the=C2=A0=C2=A0[[=
maybe_unused]] attribute could provide the same information as making it un=
named.</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/107ecab4-afa7-4ca7-b513-94538cadd52d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/107ecab4-afa7-4ca7-b513-94538cadd52d=
%40isocpp.org</a>.<br />

------=_Part_11836_822240895.1507845338252--

------=_Part_11835_1428870880.1507845338252--

.

On 2017-10-12 17:46, janwilmans@gmail.com wrote:
> What I was suggesting is that by introducing a syntax to explicitly make
> something unnamed, the compiler would then be free to emit warnings for all
> other cases where an object is not referenced after construction, without
> needed to evaluate whether the constructor/destruction has side-effects or
> not.
>
> This is what you wanted right?

Yeeeee...maybe? I seem to recall that defining "not referenced after
construction" was not so simple as it seems.

> On the other hand, I don't really see the value in putting that specific
> warning in the standard itself, but any compiler would be free do to do it
> and it would be easier to implement.

In any case, I don't think the standard would have anything stronger
than a suggestion regarding warnings. (IIRC, there is anyway no such
thing as a "warning" in the standard.) What would be proposed would be
an attribute to annotate types that should not produce such warnings.

IOW, the only actual *standardese* would be that an attribute with
such-and-such name exists.

--
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/fb43bfaa-b153-34f1-8c3f-63800d3f391e%40gmail.com.

.

On 2017-10-12 17:39, Nevin Liber wrote:
> You want opt-out, which will generate far too many false positives on
> existing, working code.  For many businesses, changing existing, working
> code has a very non-trivial cost.

Opt-out by *adding an attribute*. If that's too hard... just turn the
bloody warning off. Geez.

The problem with opt-*in* is that 98% of classes would need to be annotated.

> If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover it?

Not really; you'd have to annotate every *use* of a type that it is okay
to keep in scope but not otherwise use. [[nodiscard]] is too broad a
brush, and [[maybe_unused]] is to narrow. Plus [[nodiscard]] is opt-in,
which is wrong per above.

--
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/12295af1-dae1-b0de-d85b-c69c34faaf7f%40gmail.com.

.

On 2017-10-12 18:19, Matthew Woehlke wrote:
> On 2017-10-12 17:39, Nevin Liber wrote:
>> You want opt-out, which will generate far too many false positives on
>> existing, working code.  For many businesses, changing existing, working
>> code has a very non-trivial cost.
>
> Opt-out by *adding an attribute*. If that's too hard... just turn the
> bloody warning off. Geez.
>
> The problem with opt-*in* is that 98% of classes would need to be annotated.
>
>> If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover it?
>
> Not really; you'd have to annotate every *use* of a type that it is okay
> to keep in scope but not otherwise use. [[nodiscard]] is too broad a
> brush, and [[maybe_unused]] is to narrow. Plus [[nodiscard]] is opt-in,
> which is wrong per above.

Point of clarification: the *warning itself* should not necessarily be
on by default. Probably it should not be, initially, until users have
had time to adapt to the idea of using the new attribute, and compilers
have had time to work the kinks out of when to warn.

However, *if* the warning is enabled, the default behavior should be to
warn if a class is "unused" *unless* the class has the attribute saying
that's okay. Because... those are rare; classes which should be "used"
(besides just being constructed and left in scope) are the exception,
not the rule.

--
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/f6d48ac0-2044-1b9c-21f8-fed2f90c526d%40gmail.com.

.

------=_Part_12060_1303555741.1507859335406
Content-Type: multipart/alternative;
 boundary="----=_Part_12061_137143655.1507859335406"

------=_Part_12061_137143655.1507859335406
Content-Type: text/plain; charset="UTF-8"



On Friday, October 13, 2017 at 11:25:53 AM UTC+13, Matthew Woehlke wrote:
>
> On 2017-10-12 18:19, Matthew Woehlke wrote:
> > On 2017-10-12 17:39, Nevin Liber wrote:
> >> You want opt-out, which will generate far too many false positives on
> >> existing, working code.  For many businesses, changing existing,
> working
> >> code has a very non-trivial cost.
> >
> > Opt-out by *adding an attribute*. If that's too hard... just turn the
> > bloody warning off. Geez.
> >
> > The problem with opt-*in* is that 98% of classes would need to be
> annotated.
> >
> >> If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover
> it?
> >
> > Not really; you'd have to annotate every *use* of a type that it is okay
> > to keep in scope but not otherwise use. [[nodiscard]] is too broad a
> > brush, and [[maybe_unused]] is to narrow. Plus [[nodiscard]] is opt-in,
> > which is wrong per above.
>

My suggestion is to use an attribute that says construction only counts as
use.
And if you don't use that attribute on your class and then construct an
instance of that class but then don't call any members of it, you will get
a warning. To disable that warning, use the attribute on the class or
construct definition and it will remove the warning for all instances of
that class that are constructed but otherwise not used.

I don't mind what the attribute is called as long as it follows the
semantics I said.
You only annotate classes where construction only is ok. By default classes
that are not annotated should be considered as suspicious (and so yield a
warning) if they are constructed but otherwise not used.
I think this is the right semantics because the majority of classes in my
opinion will require no annotation. std::string being an example of
something that would require no annotation, as by default just doing
std::string s; inside a function and not calling any methods on it should
count as something you want to be warned about so you can just remove it.

Since I am suggesting that by default, none of this affects code
generation, I see why this warning can't be on by default. It would be a
little irritating, but I think it will find genuine issues straight away
and the cure is easy. Which is the whole point of it.

The standard library would be updated so classes there wouldn't warn. Old
compilers don't know about the attributes and don't care so they would not
warn. New compilers know about the attributes and also can offer additional
compile options to say disable this or ignore certain classes where the
user can't update the code base. In any case, since it doesn't affect code
generation, I'd really like to see this error on by default. It people
really feel it shouldn't be on by default to begin with, I can live with
that, but then when will it ever get put on by default. But I think as we
can't break any code with this, be brave and make it on by default.


>
> Point of clarification: the *warning itself* should not necessarily be
> on by default. Probably it should not be, initially, until users have
> had time to adapt to the idea of using the new attribute, and compilers
> have had time to work the kinks out of when to warn.
>
> However, *if* the warning is enabled, the default behavior should be to
> warn if a class is "unused" *unless* the class has the attribute saying
> that's okay. Because... those are rare; classes which should be "used"
> (besides just being constructed and left in scope) are the exception,
> not the rule.
>
> --
> 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/e571adb8-99cb-4f47-8ce6-f4aa08881a5c%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, October 13, 2017 at 11:25:53 AM UTC+13,=
 Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;">On 2017-10-12 18:19, Ma=
tthew Woehlke wrote:
<br>&gt; On 2017-10-12 17:39, Nevin Liber wrote:
<br>&gt;&gt; You want opt-out, which will generate far too many false posit=
ives on
<br>&gt;&gt; existing, working code. =C2=A0For many businesses, changing ex=
isting, working
<br>&gt;&gt; code has a very non-trivial cost.
<br>&gt;=20
<br>&gt; Opt-out by *adding an attribute*. If that&#39;s too hard... just t=
urn the
<br>&gt; bloody warning off. Geez.
<br>&gt;=20
<br>&gt; The problem with opt-*in* is that 98% of classes would need to be =
annotated.
<br>&gt;=20
<br>&gt;&gt; If it were opt-in, do [[maybe_unused]] and [[nodiscard]] alrea=
dy cover it?
<br>&gt;=20
<br>&gt; Not really; you&#39;d have to annotate every *use* of a type that =
it is okay
<br>&gt; to keep in scope but not otherwise use. [[nodiscard]] is too broad=
 a
<br>&gt; brush, and [[maybe_unused]] is to narrow. Plus [[nodiscard]] is op=
t-in,
<br>&gt; which is wrong per above.
<br></blockquote><div><br></div><div>My=C2=A0suggestion is=C2=A0to use=C2=
=A0an attribute=C2=A0that says construction only counts as use.</div><div>A=
nd if you don&#39;t use that attribute on your class and then construct an =
instance of that class but then don&#39;t call any members of it, you will =
get a warning. To disable that warning, use the attribute on the class or c=
onstruct definition and it will remove the warning for all instances of tha=
t class that are constructed but otherwise not used.</div><div><br></div><d=
iv>I don&#39;t mind what the attribute is called as long as it follows the =
semantics I said.</div><div>You only annotate classes where construction on=
ly is ok. By default classes that are not annotated should be considered as=
=C2=A0suspicious (and so yield a warning) if they are constructed but other=
wise not used.</div><div>I think this is the right semantics because the ma=
jority of classes in my opinion will require no annotation. std::string bei=
ng an example of something that would require no annotation, as by default =
just doing std::string s; inside a function and not calling any methods on =
it should count as something you want to be warned about so you can just re=
move it.</div><div><br></div><div>Since I am suggesting that by default, no=
ne of this affects code generation, I see why this warning can&#39;t be on =
by default. It would be a little irritating, but I think it will find genui=
ne issues straight away and the cure is easy. Which is the whole point of i=
t.</div><div><br></div><div>The standard library would be updated so classe=
s there wouldn&#39;t warn. Old compilers don&#39;t know about the attribute=
s and don&#39;t care so they would not warn. New compilers know about the a=
ttributes and also can offer additional compile options to say disable this=
 or ignore certain classes where the user can&#39;t update the code base. I=
n any case, since it doesn&#39;t affect code generation, I&#39;d really lik=
e to see this error on by default. It people really feel it shouldn&#39;t b=
e on by default to begin with, I can live with that, but then when will it =
ever get put on by default.=C2=A0But I think as=C2=A0we can&#39;t break any=
 code with this,=C2=A0be brave and make it on by default.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;">
<br>Point of clarification: the *warning itself* should not necessarily be
<br>on by default. Probably it should not be, initially, until users have
<br>had time to adapt to the idea of using the new attribute, and compilers
<br>have had time to work the kinks out of when to warn.
<br>
<br>However, *if* the warning is enabled, the default behavior should be to
<br>warn if a class is &quot;unused&quot; *unless* the class has the attrib=
ute saying
<br>that&#39;s okay. Because... those are rare; classes which should be &qu=
ot;used&quot;
<br>(besides just being constructed and left in scope) are the exception,
<br>not the rule.
<br>
<br>--=20
<br>Matthew
<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/e571adb8-99cb-4f47-8ce6-f4aa08881a5c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e571adb8-99cb-4f47-8ce6-f4aa08881a5c=
%40isocpp.org</a>.<br />

------=_Part_12061_137143655.1507859335406--

------=_Part_12060_1303555741.1507859335406--

.

------=_Part_12094_1848042516.1507859809064
Content-Type: multipart/alternative;
 boundary="----=_Part_12095_2098523773.1507859809065"

------=_Part_12095_2098523773.1507859809065
Content-Type: text/plain; charset="UTF-8"

We can't break any code from this feature, by default it does not affect
optimization, so put the warnings on by default is my feeling.
The [[construction_only_is_use]] attribute (or whatever I called it) says
this class is ok to be just constructed but never otherwise used.
My attribute means just construction of this class counts as use. So
maybe_unused is wrong for that purpose as it's the opposite meaning I think.
[[nodiscard]] might work though. I'm not sure nodiscard is asclear as what
I want. But I'm open to it.

I think agree on the semantics of what I'm saying first then worry about
the name.


On Friday, October 13, 2017 at 10:54:07 AM UTC+13, janwi...@gmail.com wrote:

>
>> If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover it?
>> --
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404
>>
>
> Making it opt-in defeats the point, right? because then existing code
> would still be hit with lost of warnings, unless the warning would be off
> by default, was that would you ment?
>

--
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/b3aa9f20-7ebf-4c54-9380-b63f2d12270f%40isocpp.org.

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

<div dir=3D"ltr"><div>We can&#39;t break any code from this feature,=C2=A0b=
y default it does not affect optimization,=C2=A0so put the warnings on by d=
efault is my feeling.</div><div>The [[construction_only_is_use]] attribute =
(or whatever I called it) says this class is ok to be just constructed but =
never otherwise used.</div><div>My attribute means just construction of thi=
s class counts as use. So maybe_unused is wrong for that purpose as it&#39;=
s the opposite meaning I think.</div><div>[[nodiscard]] might work though. =
I&#39;m not sure nodiscard is asclear as what I want. But I&#39;m open to i=
t.</div><div><br></div><div>I think agree on the semantics of what I&#39;m =
saying first then worry about the name.</div><div><br><br>On Friday, Octobe=
r 13, 2017 at 10:54:07 AM UTC+13, janwi...@gmail.com wrote:</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-l=
eft-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>If it were opt=
-in, do [[maybe_unused]] and [[nodiscard]] already cover it?</div></div>-- =
<br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&=
quot; Liber=C2=A0 &lt;mailto:<a rel=3D"nofollow">ne...@eviloverlord.com</a>=
<wbr>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div></div></div></=
blockquote><div><br></div><div>Making it opt-in defeats the point, right? b=
ecause then existing code would still be hit with lost of warnings, unless =
the warning would be off by default, was that would you ment?</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/b3aa9f20-7ebf-4c54-9380-b63f2d12270f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b3aa9f20-7ebf-4c54-9380-b63f2d12270f=
%40isocpp.org</a>.<br />

------=_Part_12095_2098523773.1507859809065--

------=_Part_12094_1848042516.1507859809064--

.

------=_Part_12080_1429617778.1507860015751
Content-Type: multipart/alternative;
 boundary="----=_Part_12081_1366394336.1507860015751"

------=_Part_12081_1366394336.1507860015751
Content-Type: text/plain; charset="UTF-8"


>
> You want opt-out, which will generate far too many false positives on
> existing, working code.  For many businesses, changing existing, working
> code has a very non-trivial cost.
>
> If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cover it?
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>
>  +1-847-691-1404
>

My proposal doesn't effect any existing code, in terms of code generation
anyway. Everything will work as it did before.
Sure it might generate some diagnostics, but only for classes that have
semantics like lock_guard.
I think they will be in the minority and the fix is simply to annotate the
class or constructor with an attribute. That's it.
if the warnings are on by default I suspect it will find a reasonable
number of unused variables. You'll probably spend as much time fixing them
on a large code base as you would annotating the few classes that are
genuinely construction only types.

--
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/385a0602-0659-47a4-baad-3b176d829034%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div>You want opt-out, which will generate far too many=
 false positives on existing, working code.=C2=A0 For many businesses, chan=
ging existing, working code has a very non-trivial cost.</div><div><br></di=
v><div>If it were opt-in, do [[maybe_unused]] and [[nodiscard]] already cov=
er it?</div></div>-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=
=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" href=3D"javascript:" target=3D"_blank" rel=3D"nof=
ollow" gdf-obfuscated-mailto=3D"EPNjp0OKAAAJ">ne...@eviloverlord.com</a><wb=
r>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div></div></div></blo=
ckquote><div><br></div><div>My proposal doesn&#39;t=C2=A0effect any existin=
g code, in terms of code generation anyway. Everything will work as it did =
before.</div><div>Sure it might generate some diagnostics, but only for cla=
sses that have semantics like lock_guard.</div><div>I think they will be in=
 the minority and the fix is simply to annotate the class or constructor wi=
th an attribute. That&#39;s it.</div><div>if the warnings are on by default=
 I suspect it will find a reasonable number of unused variables. You&#39;ll=
 probably spend as much time fixing them on a large code base as you would =
annotating the few classes that are genuinely construction only types.</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/385a0602-0659-47a4-baad-3b176d829034%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/385a0602-0659-47a4-baad-3b176d829034=
%40isocpp.org</a>.<br />

------=_Part_12081_1366394336.1507860015751--

------=_Part_12080_1429617778.1507860015751--

.

On 2017-10-12 21:56, gmisocpp@gmail.com wrote:
> We can't break any code from this feature, by default it does not affect
> optimization, so put the warnings on by default is my feeling.

The reason not to enable the warning by default is that a) it will
result in new warnings in existing code, and b) some people build with
-Werror (and/or the MSVC equivalent). This is what folks are talking
about when they express concern that this would "break" existing code.

However, this all is somewhat beside the point, because it has no impact
on the standard, which does not specify warnings. Ultimately, it is the
vendors that will decide what is best for their customers as to whether
to warn by default or not.

> The [[construction_only_is_use]] attribute (or whatever I called it) says
> this class is ok to be just constructed but never otherwise used.
> My attribute means just construction of this class counts as use. So
> maybe_unused is wrong for that purpose as it's the opposite meaning I think.
> [[nodiscard]] might work though. I'm not sure nodiscard is asclear as what
> I want. But I'm open to it.

The problem with [[nodiscard]] is that it is meant to require "using"
the class... whatever that means. By itself, it is not granular enough
to cover both a class/value that really needs to be *checked*, and the
use case you're targeting (a class that just needs to stay in scope for
a bit).

I'd originally proposed two attributes: one that says "don't just drop
this on the floor", and one that says "you need to do something with
this". However, the more I think about it, that doesn't cover your use
case, which is to treat *every explicitly constructed object* as the
latter. So, actually, I think your proposed attribute is the right approach.

Yours should combine with [[nodiscard]] to say "sticking this in a
variable and keeping it around for a bit is sufficient". Without that,
you implicitly have to "do something" with the object. *Every explicit
instantiation* would implicitly become [[nodiscard]]. Explicit use of
[[nodiscard]] would be relegated to function returns, to annotate
between functions where the result is useful but not critical, and where
ignoring the result is a logic error, with class use viewed as a
convenience for implicitly marking all function uses that return that
type (which is the case today, anyway).

I'm not sure if it's reasonable to argue that [[maybe_unused]], applied
to a type, should have that effect. Mostly because it seems confusing.
However, I could possibly entertain an argument to that effect.

--
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/fe3c0f37-f13d-9796-95c1-2a844d5e448f%40gmail.com.

.

--94eb2c04a148d15225055b6ecd04
Content-Type: text/plain; charset="UTF-8"

Fully agree, with a side-note, that making the object unnamed would be
identical to marking it with attributes that say "keeping this around for a
bit is sufficient", with an added bonus of not _being able_ to do anything
else with it.

--
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/CADtNNhjOw72Q5NGmQK-cEABjC_sHTZK5VHcMRGyL%3DO67WesMVg%40mail.gmail.com.

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

<div dir=3D"ltr">Fully agree, with a side-note, that making the object unna=
med would be identical to marking it with attributes that say &quot;<span s=
tyle=3D"font-size:12.8px">keeping this around for a bit is sufficient&quot;=
, with an added bonus of not _being able_ to do anything else with it.</spa=
n><div class=3D"gmail_extra">
</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/CADtNNhjOw72Q5NGmQK-cEABjC_sHTZK5VHcM=
RGyL%3DO67WesMVg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADtNNhjOw72Q5N=
GmQK-cEABjC_sHTZK5VHcMRGyL%3DO67WesMVg%40mail.gmail.com</a>.<br />

--94eb2c04a148d15225055b6ecd04--

.

On 2017-10-13 10:52, Jan Wilmans wrote:
> Fully agree, with a side-note, that making the object unnamed would be
> identical to marking it with attributes that say "keeping this around for a
> bit is sufficient", with an added bonus of not _being able_ to do anything
> else with it.

On the one hand, I see the utility when the type is a "legacy" type
that's okay if the only "use" is constructing it and keeping it around a
bit. OTOH, if the type is *not* such a critter, you're allowing users to
write garbage like `unnamed std::string{"Hello!"};` with no warning.

I think I'd prefer allowing to mark declarations (anonymous or
otherwise) with the new attribute for cases that the type itself is not
marked, but should have been.

--
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/964a3896-5ca7-f9a3-139c-18b12537c83b%40gmail.com.

.

------=_Part_13436_599571611.1507929149238
Content-Type: multipart/alternative;
 boundary="----=_Part_13437_307334962.1507929149238"

------=_Part_13437_307334962.1507929149238
Content-Type: text/plain; charset="UTF-8"



On Saturday, October 14, 2017 at 3:11:07 AM UTC+13, Matthew Woehlke wrote:
>
> On 2017-10-12 21:56, gmis...@gmail.com <javascript:> wrote:
> > We can't break any code from this feature, by default it does not affect
> > optimization, so put the warnings on by default is my feeling.
>
> The reason not to enable the warning by default is that a) it will
> result in new warnings in existing code, and b) some people build with
> -Werror (and/or the MSVC equivalent). This is what folks are talking
> about when they express concern that this would "break" existing code.
>
> However, this all is somewhat beside the point, because it has no impact
> on the standard, which does not specify warnings. Ultimately, it is the
> vendors that will decide what is best for their customers as to whether
> to warn by default or not.
>
>
>
If this feature ever sees the light of day then I suspect you will be right
about it not being on by default because of the reasons you say but I'll be
disappointed if is for these reasons never the less.
I think -Werror is all well and good, but personally, I don't think my
suggested diagnostic should obey this flag, not without some addition
-WIreallymeanit flag anyway. Because the warning isn't likely to mean any
code is broken. It's not meant to affect any code generation at all. It
typically means you've left an object in that isn't used like the redundant
std::string from my example and that will likely be optimized away anyway.

I would be quite happy that this warning actually be classes as an
"informational" message which I think some compilers can issue (so it's
neither a warning nor an error) if the idea would appease people to get on
by default. I'd be interested what people think about that idea and if they
are against on by default. I'm really quite for on by default for this
feature. But obviously not at the cost of not getting it at all. It'd be
great to have a strong rationale for it being on by default even if vendors
ultimately do what they want to do with regard to warnings, I think this is
a simple feature though that should ideally have some baseline consistent
level of support across compilers.








--
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/fc6325d5-8ee8-4a61-ac28-75c2412dabcb%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Saturday, October 14, 2017 at 3:11:07 AM UTC+13=
, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;">On 2017-10-12 21:56, <=
a onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" targe=
t=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"NDwMp0_AAAAJ">gmis..=
..@gmail.com</a> wrote:
<br>&gt; We can&#39;t break any code from this feature, by default it does =
not affect=20
<br>&gt; optimization, so put the warnings on by default is my feeling.
<br>
<br>The reason not to enable the warning by default is that a) it will
<br>result in new warnings in existing code, and b) some people build with
<br>-Werror (and/or the MSVC equivalent). This is what folks are talking
<br>about when they express concern that this would &quot;break&quot; exist=
ing code.
<br>
<br>However, this all is somewhat beside the point, because it has no impac=
t
<br>on the standard, which does not specify warnings. Ultimately, it is the
<br>vendors that will decide what is best for their customers as to whether
<br>to warn by default or not.
<br>
<br><br></blockquote><div><br></div><div>If this feature ever sees the ligh=
t of day then I suspect you will be right about it not being on by default =
because of the reasons you say but I&#39;ll be disappointed if is for these=
 reasons never the less.</div><div>I think -Werror is all well and good, bu=
t personally, I don&#39;t think my suggested diagnostic should obey this fl=
ag, not without some addition -WIreallymeanit flag anyway. Because the=C2=
=A0warning isn&#39;t likely to mean any code is broken. It&#39;s not meant =
to affect any code generation at all. It typically means you&#39;ve left an=
 object in that isn&#39;t used like=C2=A0the redundant std::string from my =
example and that will likely be optimized away anyway.</div><div><br></div>=
<div>I would be quite happy that this warning actually be classes as an &qu=
ot;informational&quot; message which I think some compilers can issue (so i=
t&#39;s neither a warning nor an error) if=C2=A0the idea=C2=A0would appease=
 people to get on by default. I&#39;d be interested what people think about=
 that idea and=C2=A0if they are against on by default. I&#39;m really quite=
 for on by default for this feature. But obviously not at the cost of not g=
etting=C2=A0it at all. It&#39;d be great to have a strong rationale for it =
being on by default even if vendors ultimately do what they want to do with=
 regard to warnings, I think this is a simple feature though that=C2=A0shou=
ld=C2=A0ideally have=C2=A0some baseline consistent level of support across =
compilers.</div><div><br></div><div><br></div><div><br></div><div><br></div=
><div><br></div><div><br></div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/fc6325d5-8ee8-4a61-ac28-75c2412dabcb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fc6325d5-8ee8-4a61-ac28-75c2412dabcb=
%40isocpp.org</a>.<br />

------=_Part_13437_307334962.1507929149238--

------=_Part_13436_599571611.1507929149238--

.