A recent thread=C2=B9 on std-discussion brought up an interesting question.
Consider the following code:

  {
    auto x =3D return_something_important();
    // do other stuff that doesn't use 'x'
  }

Is this an error? (Note that I mean a "you're using it wrong" error, not
ill-formed code.)

Well... it depends on just what sort of "important" thing was returned.
If it was an RAII object, it is probably okay (and moreover, it might be
nice for the compiler to shut up about `x` being unused without having
to mark it explicitly). If it was an error code=C2=B2, it is probably not
okay; although the error code was not "discarded", it wasn't inspected
either.

We have [[nodiscard]] for this general class of problems, but it isn't
sufficiently fine-grained to distinguish these cases. Moreover, the
above code can't be written to warn appropriately. As is, it will likely
generate a spurious warning in the RAII object case. On the other hand,
we are hoping that the compiler warns about the unused variable. If we
get anonymous variables, we might like for the compiler to warn about
assigning the error code to an anonymous.

So... should we add a second, similar attribute to allow these cases to
be distinguished? If so, which case should [[nodiscard]] handle, and
what do we name the new attribute?

(As a secondary question, should we have an [[unused]] that warns if you
try to use it after all? Hopefully, anonymous variables could eliminate
the use case for this.)

(=C2=B9
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/dE1ubDI3--c/7JF=
iMLXuBwAJ)

(=C2=B2 ...or the result of an accessor function with no side effects.
Calling such a function and ignoring the result is almost certainly an
error, because nothing was accomplished by the call, which may indicate
that the caller is confused as to the purpose of the function. A popular
example is std::vector::empty().)

--=20
Matthew

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

.

------=_Part_697_1493312300.1484344630906
Content-Type: multipart/alternative;
 boundary="----=_Part_698_226749759.1484344630906"

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

On Friday, January 13, 2017 at 4:21:04 PM UTC-5, Matthew Woehlke wrote:
>
> A recent thread=C2=B9 on std-discussion brought up an interesting questio=
n.=20
> Consider the following code:=20
>
>   {=20
>     auto x =3D return_something_important();=20
>     // do other stuff that doesn't use 'x'=20
>   }=20
>
> Is this an error? (Note that I mean a "you're using it wrong" error, not=
=20
> ill-formed code.)
>

I think it's best to examine this with 3 actual functions/types that we=20
would like to employ it in:

1: *`std::async`*: The textbook case for [[nodiscard]]. Dropping that=20
return value on the floor is not just useless; it's *negatively useful*.=20
It's clearly not what you wanted.

But in your above code, this is perfectly fine. At least in theory. You=20
start an async process, then do something else, and afterwards join=20
automatically. There's nothing wrong with that code. And if the `future` is=
=20
`void`, then there's no reason for you to manually inspect it; you just=20
want the thread to join.

2: *`container::empty`*: Dropping that return value on the floor is not=20
helpful. Indeed, it probably means you called the wrong function.

At the same time, just storing the return value is also not helpful. You're=
=20
supposed to do something with it; otherwise, you wouldn't have asked for it=
..

3: *`std::unique_lock`*: Dropping this on the floor is not helpful, and is=
=20
almost certainly what you don't want to do.

At the same time, you may not want to *store* it in a variable. As Richard=
=20
mentioned in the other thread:

unique_lock<mutex>(m), do_something_with_lock_held();

That is odd, but it is functionally OK. And the compiler need not complain=
=20
about it.

So what we have are the following cases:

1: Don't drop it on the floor, but capturing it in a variable is fine,=20
regardless of how it gets used.

2: Don't drop it on the floor, but just capturing the value is not enough.=
=20
You need to do something with it.

3: Some code needs to execute after the constructor is finished but before=
=20
the destructor is called.

Now personally, I don't think it's reasonable to detect #2. There are too=
=20
many ways to define "do something with it" for us to catch them all. `x =3D=
=3D=20
x` could be considered doing something.

I think it's best to let #1 ([[nodiscard]]) handle #2 as best it can. If=20
users deliberately choose to catch them in a variable and not use them,=20
then I say that they're doing it to specifically avoid the [[nodiscard]]=20
warning. So let them.

Now, I have no idea how #3 should be spelled. But [[nodiscard]] seems an=20
adequate spelling for #1/#2.

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

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

<div dir=3D"ltr">On Friday, January 13, 2017 at 4:21:04 PM UTC-5, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">A recent thread=
=C2=B9 on std-discussion brought up an interesting question.
<br>Consider the following code:
<br>
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 auto x =3D return_something_important();
<br>=C2=A0 =C2=A0 // do other stuff that doesn&#39;t use &#39;x&#39;
<br>=C2=A0 }
<br>
<br>Is this an error? (Note that I mean a &quot;you&#39;re using it wrong&q=
uot; error, not
<br>ill-formed code.)<br></blockquote><div><br>I think it&#39;s best to exa=
mine this with 3 actual functions/types that we would like to employ it in:=
<br><br>1: <b>`std::async`</b>: The textbook case for [[nodiscard]]. Droppi=
ng that return value on the floor is not just useless; it&#39;s <i>negative=
ly useful</i>. It&#39;s clearly not what you wanted.<br><br>But in your abo=
ve code, this is perfectly fine. At least in theory. You start an async pro=
cess, then do something else, and afterwards join automatically. There&#39;=
s nothing wrong with that code. And if the `future` is `void`, then there&#=
39;s no reason for you to manually inspect it; you just want the thread to =
join.<br><br>2: <b>`container::empty`</b>: Dropping that return value on th=
e floor is not helpful. Indeed, it probably means you called the wrong func=
tion.<br><br>At the same time, just storing the return value is also not he=
lpful. You&#39;re supposed to do something with it; otherwise, you wouldn&#=
39;t have asked for it.<br><br>3: <b>`std::unique_lock`</b>: Dropping this =
on the floor is not helpful, and is almost certainly what you don&#39;t wan=
t to do.<br><br>At the same time, you may not want to <i>store</i> it in a =
variable. As Richard mentioned in the other thread:<br><br><div style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">unique_lock</span><span =
style=3D"color: #080;" class=3D"styled-by-prettify">&lt;mutex&gt;</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">m</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> do_something_with_lock_held</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span></div></code></di=
v><br>That is odd, but it is functionally OK. And the compiler need not com=
plain about it.<br><br>So what we have are the following cases:<br><br>1: D=
on&#39;t drop it on the floor, but capturing it in a variable is fine, rega=
rdless of how it gets used.<br><br>2: Don&#39;t drop it on the floor, but j=
ust capturing the value is not enough. You need to do something with it.<br=
><br>3: Some code needs to execute after the constructor is finished but be=
fore the destructor is called.<br><br>Now personally, I don&#39;t think it&=
#39;s reasonable to detect #2. There are too many ways to define &quot;do s=
omething with it&quot; for us to catch them all. `x =3D=3D x` could be cons=
idered doing something.<br><br>I think it&#39;s best to let #1 ([[nodiscard=
]]) handle #2 as best it can. If users deliberately choose to catch them in=
 a variable and not use them, then I say that they&#39;re doing it to speci=
fically avoid the [[nodiscard]] warning. So let them.<br><br>Now, I have no=
 idea how #3 should be spelled. But [[nodiscard]] seems an adequate spellin=
g for #1/#2.</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/c283d24d-a9e9-437d-89db-bc8102c0691b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c283d24d-a9e9-437d-89db-bc8102c0691b=
%40isocpp.org</a>.<br />

------=_Part_698_226749759.1484344630906--

------=_Part_697_1493312300.1484344630906--

.

On 2017-01-13 16:57, Nicol Bolas wrote:
> On Friday, January 13, 2017 at 4:21:04 PM UTC-5, Matthew Woehlke wrote:
>>
>> A recent thread=C2=B9 on std-discussion brought up an interesting questi=
on.=20
>> Consider the following code:=20
>>
>>   {=20
>>     auto x =3D return_something_important();=20
>>     // do other stuff that doesn't use 'x'=20
>>   }=20
>>
>> Is this an error? (Note that I mean a "you're using it wrong" error, not=
=20
>> ill-formed code.)
>=20
> I think it's best to examine this with 3 actual functions/types that we=
=20
> would like to employ it in:
>=20
> 1: *`std::async`*: The textbook case for [[nodiscard]]. Dropping that=20
> return value on the floor is not just useless; it's *negatively useful*.=
=20
> It's clearly not what you wanted.
>=20
> But in your above code, this is perfectly fine. At least in theory. You=
=20
> start an async process, then do something else, and afterwards join=20
> automatically. There's nothing wrong with that code. And if the `future` =
is=20
> `void`, then there's no reason for you to manually inspect it; you just=
=20
> want the thread to join.
>=20
> 2: *`container::empty`*: Dropping that return value on the floor is not=
=20
> helpful. Indeed, it probably means you called the wrong function.
>=20
> At the same time, just storing the return value is also not helpful. You'=
re=20
> supposed to do something with it; otherwise, you wouldn't have asked for =
it.
>=20
> 3: *`std::unique_lock`*: Dropping this on the floor is not helpful, and i=
s=20
> almost certainly what you don't want to do.
>=20
> At the same time, you may not want to *store* it in a variable. As Richar=
d=20
> mentioned in the other thread:
>=20
> unique_lock<mutex>(m), do_something_with_lock_held();
>=20
> That is odd, but it is functionally OK. And the compiler need not complai=
n=20
> about it.

It's not clear to me how cases #1 and #3 differ? In both cases, it seems
you are saying that it is okay if the object immediately becomes
inaccessible (or at least, is never touched after receiving it, other
than when it is destroyed at the end of its scope), as long as something
else happens before the object is destroyed.

In particular, maybe I write:

  run_asynchronously(long_task_1), long_task_2();

What am I missing?

> So what we have are the following cases:
>=20
> 1: Don't drop it on the floor, but capturing it in a variable is fine,=20
> regardless of how it gets used.
>=20
> 2: Don't drop it on the floor, but just capturing the value is not enough=
..=20
> You need to do something with it.
>=20
> 3: Some code needs to execute after the constructor is finished but befor=
e=20
> the destructor is called.

Again, #1 and #3 seem to be the same?

> Now personally, I don't think it's reasonable to detect #2. There are too=
=20
> many ways to define "do something with it" for us to catch them all. `x =
=3D=3D=20
> x` could be considered doing something.

I'm not worried about that; it is QoI for compilers to provide a
reasonable definition of "do something with it". (I would say that it
must be used as the parameter of a function or operator that is not a
copy/assignment. Of course, if it gets assigned to something where the
compiler can no longer track if it is used subsequently, such as a
member or global variable, I would expect the compiler to assume
optimistically that it is used eventually. But again, we don't need to
get this right, since it is QoI.)

> I think it's best to let #1 ([[nodiscard]]) handle #2 as best it can.

This is only part of the problem. The other part is that, as I
understand it, your example above:

  get_lock(), do_something_while_locked();

....will trigger a warning if get_lock() is [[nodiscard]].

In fact, I believe the current semantics of [[nodiscard]] *almost*
exactly match what we want for case #2 (although "failure to use the
value" is caught by 'variable assigned but not used' warnings, which is
slightly sub-optimal). The problem is that it is *too strict* for cases
#1 and #3.

--=20
Matthew

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

.

------=_Part_2469_1731547570.1484350980198
Content-Type: multipart/alternative;
 boundary="----=_Part_2470_368112894.1484350980199"

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

On Friday, January 13, 2017 at 5:23:28 PM UTC-5, Matthew Woehlke wrote:
>
> On 2017-01-13 16:57, Nicol Bolas wrote:=20
> > On Friday, January 13, 2017 at 4:21:04 PM UTC-5, Matthew Woehlke wrote:=
=20
> >>=20
> >> A recent thread=C2=B9 on std-discussion brought up an interesting ques=
tion.=20
> >> Consider the following code:=20
> >>=20
> >>   {=20
> >>     auto x =3D return_something_important();=20
> >>     // do other stuff that doesn't use 'x'=20
> >>   }=20
> >>=20
> >> Is this an error? (Note that I mean a "you're using it wrong" error,=
=20
> not=20
> >> ill-formed code.)=20
> >=20
> > I think it's best to examine this with 3 actual functions/types that we=
=20
> > would like to employ it in:=20
> >=20
> > 1: *`std::async`*: The textbook case for [[nodiscard]]. Dropping that=
=20
> > return value on the floor is not just useless; it's *negatively useful*=
..=20
> > It's clearly not what you wanted.=20
> >=20
> > But in your above code, this is perfectly fine. At least in theory. You=
=20
> > start an async process, then do something else, and afterwards join=20
> > automatically. There's nothing wrong with that code. And if the `future=
`=20
> is=20
> > `void`, then there's no reason for you to manually inspect it; you just=
=20
> > want the thread to join.=20
> >=20
> > 2: *`container::empty`*: Dropping that return value on the floor is not=
=20
> > helpful. Indeed, it probably means you called the wrong function.=20
> >=20
> > At the same time, just storing the return value is also not helpful.=20
> You're=20
> > supposed to do something with it; otherwise, you wouldn't have asked fo=
r=20
> it.=20
> >=20
> > 3: *`std::unique_lock`*: Dropping this on the floor is not helpful, and=
=20
> is=20
> > almost certainly what you don't want to do.=20
> >=20
> > At the same time, you may not want to *store* it in a variable. As=20
> Richard=20
> > mentioned in the other thread:=20
> >=20
> > unique_lock<mutex>(m), do_something_with_lock_held();=20
> >=20
> > That is odd, but it is functionally OK. And the compiler need not=20
> complain=20
> > about it.=20
>
> It's not clear to me how cases #1 and #3 differ? In both cases, it seems=
=20
> you are saying that it is okay if the object immediately becomes=20
> inaccessible (or at least, is never touched after receiving it, other=20
> than when it is destroyed at the end of its scope), as long as something=
=20
> else happens before the object is destroyed.=20
>
> In particular, maybe I write:=20
>
>   run_asynchronously(long_task_1), long_task_2();=20
>
> What am I missing?
>

You might write that. But I think it's sufficiently unlikely that it's best=
=20
to warn for it anyway. Whereas lock_guards and the like are specifically=20
intended to work like this.

It's best for the creator of the class/function to determine which they=20
want: do they want the above code to be reasonable or do they not?

> So what we have are the following cases:=20
> >=20
> > 1: Don't drop it on the floor, but capturing it in a variable is fine,=
=20
> > regardless of how it gets used.=20
> >=20
> > 2: Don't drop it on the floor, but just capturing the value is not=20
> enough.=20
> > You need to do something with it.=20
> >=20
> > 3: Some code needs to execute after the constructor is finished but=20
> before=20
> > the destructor is called.=20
>
> Again, #1 and #3 seem to be the same?=20
>
> > Now personally, I don't think it's reasonable to detect #2. There are=
=20
> too=20
> > many ways to define "do something with it" for us to catch them all. `x=
=20
> =3D=3D=20
> > x` could be considered doing something.=20
>
> I'm not worried about that; it is QoI for compilers to provide a=20
> reasonable definition of "do something with it".


Absolutely not.

The standard has a good definition of what "discard" means, so the only=20
implementation variance would be whether implementations warn on all of=20
those cases.

By contrast, "do something with it" is decidedly nebulous. There's no good=
=20
definition of what a "quality" implementation of that would even be. Who is=
=20
to say that an implementation should warn on one thing rather than another?

This is *absolutely not* the sort of thing that QoI should determine. If=20
the user applies an attribute to something in order to provoke a warning,=
=20
then there should be a clear meaning as to when the user wants that warning=
=20
to happen.

If we cannot come up with a firm definition of what that attribute means=20
and when warnings should happen because of it, then we shouldn't have it at=
=20
all. There is no QoI when it comes to [[noreturn]], [[fallthrough]], and=20
other attributes. Why should the use of this attribute rely on QoI?
=20

> (I would say that it=20
> must be used as the parameter of a function or operator that is not a=20
> copy/assignment. Of course, if it gets assigned to something where the=20
> compiler can no longer track if it is used subsequently, such as a=20
> member or global variable, I would expect the compiler to assume=20
> optimistically that it is used eventually. But again, we don't need to=20
> get this right, since it is QoI.)=20
>
> > I think it's best to let #1 ([[nodiscard]]) handle #2 as best it can.=
=20
>
> This is only part of the problem. The other part is that, as I=20
> understand it, your example above:=20
>
>   get_lock(), do_something_while_locked();=20
>
> ...will trigger a warning if get_lock() is [[nodiscard]].
>

That is case #3. Which I argued should be handled by its own attribute.=20
*You're* the one claiming that #1 and #3 are the same, not me.

In fact, I believe the current semantics of [[nodiscard]] *almost*=20
> exactly match what we want for case #2 (although "failure to use the=20
> value" is caught by 'variable assigned but not used' warnings, which is=
=20
> slightly sub-optimal). The problem is that it is *too strict* for cases=
=20
> #1 and #3.
>

Which is why #1 and #3 are different cases, which require different=20
attributes.

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

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

<div dir=3D"ltr">On Friday, January 13, 2017 at 5:23:28 PM UTC-5, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01-13 16:=
57, Nicol Bolas wrote:
<br>&gt; On Friday, January 13, 2017 at 4:21:04 PM UTC-5, Matthew Woehlke w=
rote:
<br>&gt;&gt;
<br>&gt;&gt; A recent thread=C2=B9 on std-discussion brought up an interest=
ing question.=20
<br>&gt;&gt; Consider the following code:=20
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 {=20
<br>&gt;&gt; =C2=A0 =C2=A0 auto x =3D return_something_important();=20
<br>&gt;&gt; =C2=A0 =C2=A0 // do other stuff that doesn&#39;t use &#39;x&#3=
9;=20
<br>&gt;&gt; =C2=A0 }=20
<br>&gt;&gt;
<br>&gt;&gt; Is this an error? (Note that I mean a &quot;you&#39;re using i=
t wrong&quot; error, not=20
<br>&gt;&gt; ill-formed code.)
<br>&gt;=20
<br>&gt; I think it&#39;s best to examine this with 3 actual functions/type=
s that we=20
<br>&gt; would like to employ it in:
<br>&gt;=20
<br>&gt; 1: *`std::async`*: The textbook case for [[nodiscard]]. Dropping t=
hat=20
<br>&gt; return value on the floor is not just useless; it&#39;s *negativel=
y useful*.=20
<br>&gt; It&#39;s clearly not what you wanted.
<br>&gt;=20
<br>&gt; But in your above code, this is perfectly fine. At least in theory=
.. You=20
<br>&gt; start an async process, then do something else, and afterwards joi=
n=20
<br>&gt; automatically. There&#39;s nothing wrong with that code. And if th=
e `future` is=20
<br>&gt; `void`, then there&#39;s no reason for you to manually inspect it;=
 you just=20
<br>&gt; want the thread to join.
<br>&gt;=20
<br>&gt; 2: *`container::empty`*: Dropping that return value on the floor i=
s not=20
<br>&gt; helpful. Indeed, it probably means you called the wrong function.
<br>&gt;=20
<br>&gt; At the same time, just storing the return value is also not helpfu=
l. You&#39;re=20
<br>&gt; supposed to do something with it; otherwise, you wouldn&#39;t have=
 asked for it.
<br>&gt;=20
<br>&gt; 3: *`std::unique_lock`*: Dropping this on the floor is not helpful=
, and is=20
<br>&gt; almost certainly what you don&#39;t want to do.
<br>&gt;=20
<br>&gt; At the same time, you may not want to *store* it in a variable. As=
 Richard=20
<br>&gt; mentioned in the other thread:
<br>&gt;=20
<br>&gt; unique_lock&lt;mutex&gt;(m), do_something_with_lock_held();
<br>&gt;=20
<br>&gt; That is odd, but it is functionally OK. And the compiler need not =
complain=20
<br>&gt; about it.
<br>
<br>It&#39;s not clear to me how cases #1 and #3 differ? In both cases, it =
seems
<br>you are saying that it is okay if the object immediately becomes
<br>inaccessible (or at least, is never touched after receiving it, other
<br>than when it is destroyed at the end of its scope), as long as somethin=
g
<br>else happens before the object is destroyed.
<br>
<br>In particular, maybe I write:
<br>
<br>=C2=A0 run_asynchronously(long_task_<wbr>1), long_task_2();
<br>
<br>What am I missing?<br></blockquote><div><br>You might write that. But I=
 think it&#39;s sufficiently unlikely that it&#39;s best to warn for it any=
way. Whereas lock_guards and the like are specifically intended to work lik=
e this.<br><br>It&#39;s best for the creator of the class/function to deter=
mine which they want: do they want the above code to be reasonable or do th=
ey not?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; So what we have are the following cases:
<br>&gt;=20
<br>&gt; 1: Don&#39;t drop it on the floor, but capturing it in a variable =
is fine,=20
<br>&gt; regardless of how it gets used.
<br>&gt;=20
<br>&gt; 2: Don&#39;t drop it on the floor, but just capturing the value is=
 not enough.=20
<br>&gt; You need to do something with it.
<br>&gt;=20
<br>&gt; 3: Some code needs to execute after the constructor is finished bu=
t before=20
<br>&gt; the destructor is called.
<br>
<br>Again, #1 and #3 seem to be the same?
<br>
<br>&gt; Now personally, I don&#39;t think it&#39;s reasonable to detect #2=
.. There are too=20
<br>&gt; many ways to define &quot;do something with it&quot; for us to cat=
ch them all. `x =3D=3D=20
<br>&gt; x` could be considered doing something.
<br>
<br>I&#39;m not worried about that; it is QoI for compilers to provide a
<br>reasonable definition of &quot;do something with it&quot;.</blockquote>=
<div><br>Absolutely not.<br><br>The standard has a good definition of what =
&quot;discard&quot; means, so the only implementation variance would be whe=
ther implementations warn on all of those cases.<br><br>By contrast, &quot;=
do something with it&quot; is decidedly nebulous. There&#39;s no good defin=
ition of what a &quot;quality&quot; implementation of that would even be. W=
ho is to say that an implementation should warn on one thing rather than an=
other?<br><br>This is <i>absolutely not</i> the sort of thing that QoI shou=
ld determine. If the user applies an attribute to something in order to pro=
voke a warning, then there should be a clear meaning as to when the user wa=
nts that warning to happen.<br><br>If we cannot come up with a firm definit=
ion of what that attribute means and when warnings should happen because of=
 it, then we shouldn&#39;t have it at all. There is no QoI when it comes to=
 [[noreturn]], [[fallthrough]], and other attributes. Why should the use of=
 this attribute rely on QoI?<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">(I would say that it
<br>must be used as the parameter of a function or operator that is not a
<br>copy/assignment. Of course, if it gets assigned to something where the
<br>compiler can no longer track if it is used subsequently, such as a
<br>member or global variable, I would expect the compiler to assume
<br>optimistically that it is used eventually. But again, we don&#39;t need=
 to
<br>get this right, since it is QoI.)
<br>
<br>&gt; I think it&#39;s best to let #1 ([[nodiscard]]) handle #2 as best =
it can.
<br>
<br>This is only part of the problem. The other part is that, as I
<br>understand it, your example above:
<br>
<br>=C2=A0 get_lock(), do_something_while_locked();
<br>
<br>...will trigger a warning if get_lock() is [[nodiscard]].<br></blockquo=
te><div><br>That is case #3. Which I argued should be handled by its own at=
tribute. <i>You&#39;re</i> the one claiming that #1 and #3 are the same, no=
t me.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
In fact, I believe the current semantics of [[nodiscard]] *almost*
<br>exactly match what we want for case #2 (although &quot;failure to use t=
he
<br>value&quot; is caught by &#39;variable assigned but not used&#39; warni=
ngs, which is
<br>slightly sub-optimal). The problem is that it is *too strict* for cases
<br>#1 and #3.<br></blockquote><div><br>Which is why #1 and #3 are differen=
t cases, which require different attributes.<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/97124a5c-1bea-47e0-9962-f1078820989e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97124a5c-1bea-47e0-9962-f1078820989e=
%40isocpp.org</a>.<br />

------=_Part_2470_368112894.1484350980199--

------=_Part_2469_1731547570.1484350980198--

.

On 14 January 2017 at 01:43, Nicol Bolas <jmckesson@gmail.com> wrote:
>> In particular, maybe I write:
>>
>>   run_asynchronously(long_task_1), long_task_2();
>>
>> What am I missing?
>
>
> You might write that. But I think it's sufficiently unlikely that it's best
> to warn for it anyway. Whereas lock_guards and the like are specifically
> intended to work like this.

Whether person X or person Y does or does not write that is all the
more reason to
be cautious about what we specify.

>> I'm not worried about that; it is QoI for compilers to provide a
>> reasonable definition of "do something with it".
>
>
> Absolutely not.
>
> The standard has a good definition of what "discard" means, so the only
> implementation variance would be whether implementations warn on all of
> those cases.

To be pedantic, there's a fairly infinite spectrum of what [[discard]] means,
from ignoring it to rendering a variety of violations of it ill-formed. It's
an attribute, and like most attributes, it has no semantic effect, besides
how many times it appears in an attribute-list. That's all that the standard
normatively specifies, anything further than that is QoI.

--
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/CAFk2RUaURX7O_wXOd8%2B4eEEFFhxUk7sbXdjUARD1TV1snpvJNQ%40mail.gmail.com.

.

On sexta-feira, 13 de janeiro de 2017 13:57:10 PST Nicol Bolas wrote:
> 2: *`container::empty`*: Dropping that return value on the floor is not
> helpful. Indeed, it probably means you called the wrong function.
>
> At the same time, just storing the return value is also not helpful. You're
> supposed to do something with it; otherwise, you wouldn't have asked for it.

That's usually the "variable initialised but not used" warning.

But compilers usually only print them for primitive types.

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

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2504053.f6eMU5nanW%40tjmaciei-mobl1.

.

------=_Part_795_1446097658.1484406155629
Content-Type: multipart/alternative;
 boundary="----=_Part_796_1880807458.1484406155629"

------=_Part_796_1880807458.1484406155629
Content-Type: text/plain; charset=UTF-8

On Friday, January 13, 2017 at 6:54:09 PM UTC-5, Ville Voutilainen wrote:
>
> On 14 January 2017 at 01:43, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> In particular, maybe I write:
> >>
> >>   run_asynchronously(long_task_1), long_task_2();
> >>
> >> What am I missing?
> >
> >
> > You might write that. But I think it's sufficiently unlikely that it's
> best
> > to warn for it anyway. Whereas lock_guards and the like are specifically
> > intended to work like this.
>
> Whether person X or person Y does or does not write that is all the
> more reason to
> be cautious about what we specify.
>
> >> I'm not worried about that; it is QoI for compilers to provide a
> >> reasonable definition of "do something with it".
> >
> >
> > Absolutely not.
> >
> > The standard has a good definition of what "discard" means, so the only
> > implementation variance would be whether implementations warn on all of
> > those cases.
>
> To be pedantic, there's a fairly infinite spectrum of what [[discard]]
> means,
> from ignoring it to rendering a variety of violations of it ill-formed.
> It's
> an attribute, and like most attributes, it has no semantic effect, besides
> how many times it appears in an attribute-list. That's all that the
> standard
> normatively specifies, anything further than that is QoI.
>

Sure, how the diagnostic is presented is up to the implementation. But when
a diagnostic is warranted is not.

--
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/83098a6c-98ae-4d3d-b45b-a45d4ade2a8e%40isocpp.org.

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

<div dir=3D"ltr">On Friday, January 13, 2017 at 6:54:09 PM UTC-5, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 January 2=
017 at 01:43, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"ijJVKeb5BgAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; In particular, maybe I write:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 run_asynchronously(long_task_<wbr>1), long_task_2();
<br>&gt;&gt;
<br>&gt;&gt; What am I missing?
<br>&gt;
<br>&gt;
<br>&gt; You might write that. But I think it&#39;s sufficiently unlikely t=
hat it&#39;s best
<br>&gt; to warn for it anyway. Whereas lock_guards and the like are specif=
ically
<br>&gt; intended to work like this.
<br>
<br>Whether person X or person Y does or does not write that is all the
<br>more reason to
<br>be cautious about what we specify.
<br>
<br>&gt;&gt; I&#39;m not worried about that; it is QoI for compilers to pro=
vide a
<br>&gt;&gt; reasonable definition of &quot;do something with it&quot;.
<br>&gt;
<br>&gt;
<br>&gt; Absolutely not.
<br>&gt;
<br>&gt; The standard has a good definition of what &quot;discard&quot; mea=
ns, so the only
<br>&gt; implementation variance would be whether implementations warn on a=
ll of
<br>&gt; those cases.
<br>
<br>To be pedantic, there&#39;s a fairly infinite spectrum of what [[discar=
d]] means,
<br>from ignoring it to rendering a variety of violations of it ill-formed.=
 It&#39;s
<br>an attribute, and like most attributes, it has no semantic effect, besi=
des
<br>how many times it appears in an attribute-list. That&#39;s all that the=
 standard
<br>normatively specifies, anything further than that is QoI.
<br></blockquote><div><br>Sure, how the diagnostic is presented is up to th=
e implementation. But when a diagnostic is warranted is not.<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/83098a6c-98ae-4d3d-b45b-a45d4ade2a8e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83098a6c-98ae-4d3d-b45b-a45d4ade2a8e=
%40isocpp.org</a>.<br />

------=_Part_796_1880807458.1484406155629--

------=_Part_795_1446097658.1484406155629--

.

------=_Part_791_159736947.1484407640334
Content-Type: multipart/alternative;
 boundary="----=_Part_792_1983434481.1484407640334"

------=_Part_792_1983434481.1484407640334
Content-Type: text/plain; charset=UTF-8

On Friday, January 13, 2017 at 11:57:10 PM UTC-5, Thiago Macieira wrote:
>
> On sexta-feira, 13 de janeiro de 2017 13:57:10 PST Nicol Bolas wrote:
> > 2: *`container::empty`*: Dropping that return value on the floor is not
> > helpful. Indeed, it probably means you called the wrong function.
> >
> > At the same time, just storing the return value is also not helpful.
> You're
> > supposed to do something with it; otherwise, you wouldn't have asked for
> it.
>
> That's usually the "variable initialised but not used" warning.
>
> But compilers usually only print them for primitive types.
>

Once [[maybe_unused]] gets more widely available, I expect more warnings of
this sort.

Also, I would say that compilers ought to warn for any type that is not
trivially destructible.

--
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/412b1d2b-66c9-4f45-b21f-638a03a2f24c%40isocpp.org.

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

<div dir=3D"ltr">On Friday, January 13, 2017 at 11:57:10 PM UTC-5, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, =
13 de janeiro de 2017 13:57:10 PST Nicol Bolas wrote:
<br>&gt; 2: *`container::empty`*: Dropping that return value on the floor i=
s not
<br>&gt; helpful. Indeed, it probably means you called the wrong function.
<br>&gt;=20
<br>&gt; At the same time, just storing the return value is also not helpfu=
l. You&#39;re
<br>&gt; supposed to do something with it; otherwise, you wouldn&#39;t have=
 asked for it.
<br>
<br>That&#39;s usually the &quot;variable initialised but not used&quot; wa=
rning.
<br>
<br>But compilers usually only print them for primitive types.
<br></blockquote><div><br>Once [[maybe_unused]] gets more widely available,=
 I expect more warnings of this sort.<br><br>Also, I would say that compile=
rs ought to warn for any type that is not trivially destructible.</div></di=
v>

<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/412b1d2b-66c9-4f45-b21f-638a03a2f24c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/412b1d2b-66c9-4f45-b21f-638a03a2f24c=
%40isocpp.org</a>.<br />

------=_Part_792_1983434481.1484407640334--

------=_Part_791_159736947.1484407640334--

.

On 14 January 2017 at 17:02, Nicol Bolas <jmckesson@gmail.com> wrote:
>> To be pedantic, there's a fairly infinite spectrum of what [[discard]]
>> means,
>> from ignoring it to rendering a variety of violations of it ill-formed.
>> It's
>> an attribute, and like most attributes, it has no semantic effect, besides
>> how many times it appears in an attribute-list. That's all that the
>> standard
>> normatively specifies, anything further than that is QoI.
>
>
> Sure, how the diagnostic is presented is up to the implementation. But when
> a diagnostic is warranted is not.


Yes it is. There's just a Note that contains "Implementations are
encouraged to issue a warning in such cases."
Implementations are not required to issue any diagnostics, nor is it
specified when they would produce
a diagnostic if they do produce any.

--
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/CAFk2RUbWEi13W-1%2BxCmthwBEJ-9QCqWoBmLdM0ntLskuEjhmtg%40mail.gmail.com.

.

------=_Part_817_1640624036.1484410362057
Content-Type: multipart/alternative;
 boundary="----=_Part_818_755927842.1484410362057"

------=_Part_818_755927842.1484410362057
Content-Type: text/plain; charset=UTF-8

On Saturday, January 14, 2017 at 11:01:45 AM UTC-5, Ville Voutilainen wrote:
>
> On 14 January 2017 at 17:02, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> To be pedantic, there's a fairly infinite spectrum of what [[discard]]
> >> means,
> >> from ignoring it to rendering a variety of violations of it ill-formed.
> >> It's
> >> an attribute, and like most attributes, it has no semantic effect,
> besides
> >> how many times it appears in an attribute-list. That's all that the
> >> standard
> >> normatively specifies, anything further than that is QoI.
> >
> >
> > Sure, how the diagnostic is presented is up to the implementation. But
> when
> > a diagnostic is warranted is not.
>
>
> Yes it is. There's just a Note that contains "Implementations are
> encouraged to issue a warning in such cases."
> Implementations are not required to issue any diagnostics, nor is it
> specified when they would produce
> a diagnostic if they do produce any.
>

Right, but implementations are not encouraged to issue a diagnostic for
[[nodiscard]] values which are not discarded. Doing this:

auto x = foo();

is not discarding the result of `foo()`. As such, implementations are not
to issue warnings, since it does not fit "such cases".

They can issue warnings on that for other reasons, but not because you used
[[nodiscard]]. That is my point. QoI should not lead to that issuing a
warning.

--
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/6a94787e-90c7-4ea0-90d7-1fe60c6b7f00%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, January 14, 2017 at 11:01:45 AM UTC-5, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 14 Januar=
y 2017 at 17:02, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"qKCffLMuBwAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; To be pedantic, there&#39;s a fairly infinite spectrum of what=
 [[discard]]
<br>&gt;&gt; means,
<br>&gt;&gt; from ignoring it to rendering a variety of violations of it il=
l-formed.
<br>&gt;&gt; It&#39;s
<br>&gt;&gt; an attribute, and like most attributes, it has no semantic eff=
ect, besides
<br>&gt;&gt; how many times it appears in an attribute-list. That&#39;s all=
 that the
<br>&gt;&gt; standard
<br>&gt;&gt; normatively specifies, anything further than that is QoI.
<br>&gt;
<br>&gt;
<br>&gt; Sure, how the diagnostic is presented is up to the implementation.=
 But when
<br>&gt; a diagnostic is warranted is not.
<br>
<br>
<br>Yes it is. There&#39;s just a Note that contains &quot;Implementations =
are
<br>encouraged to issue a warning in such cases.&quot;
<br>Implementations are not required to issue any diagnostics, nor is it
<br>specified when they would produce
<br>a diagnostic if they do produce any.<br></blockquote><div><br>Right, bu=
t implementations are not encouraged to issue a diagnostic for [[nodiscard]=
] values which are not discarded. Doing this:<br><br><div style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettypri=
nt"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span></div></code></div><br>is not discarding the=
 result of `foo()`. As such, implementations are not to issue warnings, sin=
ce it does not fit &quot;such cases&quot;.<br><br>They can issue warnings o=
n that for other reasons, but not because you used [[nodiscard]]. That is m=
y point. QoI should not lead to that issuing a warning.<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/6a94787e-90c7-4ea0-90d7-1fe60c6b7f00%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a94787e-90c7-4ea0-90d7-1fe60c6b7f00=
%40isocpp.org</a>.<br />

------=_Part_818_755927842.1484410362057--

------=_Part_817_1640624036.1484410362057--

.

A recent thread=C2=B9 on std-discussion brought up an interesting question.
Consider the following code:

  {
    auto x =3D return_something_important();
    // do other stuff that doesn't use 'x'
  }

Is this an error? (Note that I mean a "you're using it wrong" error, not
ill-formed code.)

Well... it depends on just what sort of "important" thing was returned.
If it was an RAII object, it is probably okay (and moreover, it might be
nice for the compiler to shut up about `x` being unused without having
to mark it explicitly). If it was an error code=C2=B2, it is probably not
okay; although the error code was not "discarded", it wasn't inspected
either.

We have [[nodiscard]] for this general class of problems, but it isn't
sufficiently fine-grained to distinguish these cases. Moreover, the
above code can't be written to warn appropriately. As is, it will likely
generate a spurious warning in the RAII object case. On the other hand,
we are hoping that the compiler warns about the unused variable. If we
get anonymous variables, we might like for the compiler to warn about
assigning the error code to an anonymous.

So... should we add a second, similar attribute to allow these cases to
be distinguished? If so, which case should [[nodiscard]] handle, and
what do we name the new attribute?

(As a secondary question, should we have an [[unused]] that warns if you
try to use it after all? Hopefully, anonymous variables could eliminate
the use case for this.)

(=C2=B9
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/dE1ubDI3--c/7JF=
iMLXuBwAJ)

(=C2=B2 ...or the result of an accessor function with no side effects.
Calling such a function and ignoring the result is almost certainly an
error, because nothing was accomplished by the call, which may indicate
that the caller is confused as to the purpose of the function. A popular
example is std::vector::empty().)

--=20
Matthew

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

.

On 2017-01-13 18:43, Nicol Bolas wrote:
> On Friday, January 13, 2017 at 5:23:28 PM UTC-5, Matthew Woehlke wrote:
>> On 2017-01-13 16:57, Nicol Bolas wrote:
>>> Now personally, I don't think it's reasonable to detect #2. There
>>> are too many ways to define "do something with it" for us to
>>> catch them all. `x == x` could be considered doing something.
>>
>> I'm not worried about that; it is QoI for compilers to provide a
>> reasonable definition of "do something with it".
>
> Absolutely not.
>
> The standard has a good definition of what "discard" means, so the only
> implementation variance would be whether implementations warn on all of
> those cases.
>
> By contrast, "do something with it" is decidedly nebulous. There's no good
> definition of what a "quality" implementation of that would even be. Who is
> to say that an implementation should warn on one thing rather than another?

"Who" is easy: users.

We are in any case talking about *non-normative text*. Given that a
conforming compiler is free to ignore entirely the suggestion to warn
(see Ville's replies!), I don't see where it is worth blocking the
feature because we can't agree on what constitutes "use". Let the
compiler vendors sort that out from real world examples. Perhaps after
some years of that, we can amend the *suggestion* in the standard to be
more precise.

That's not to say I'm *opposed* to having quality guidance from the
get-go. Indeed, if I write a proposal for this, I would intend to have
more precise wording than "do something with it". However, since we are
talking about a *guideline*, I don't see where we should get overly hung
up on getting that guideline "perfect", since compilers may (and should)
do what users want, regardless of how the guideline is worded.

>> This is only part of the problem. The other part is that, as I
>> understand it, your example above:
>>
>>   get_lock(), do_something_while_locked();
>>
>> ...will trigger a warning if get_lock() is [[nodiscard]].
>
> That is case #3. Which I argued should be handled by its own attribute.
> *You're* the one claiming that #1 and #3 are the same, not me.

You have not sufficiently convinced me otherwise.

It seems to me you want these to be handled differently:

  // case 1
  foo() /* nodiscard */, bar();

  // case 2
  {
    auto [] = foo(); // nodiscard
    bar();
  }

  // case 3
  {
    auto [[maybe_unused]] x = foo(); // nodiscard
    bar();
  }

....but all of these are semantically equivalent. I don't see a
justification for treating semantically identical code differently
depending on how it is written.

--
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/587F97ED.60308%40gmail.com.

.

On 2017-01-14 11:12, Nicol Bolas wrote:
> Implementations are not encouraged to issue a diagnostic for=20
> [[nodiscard]] values which are not discarded. Doing this:
>=20
> auto x =3D foo();
>=20
> is not discarding the result of `foo()`. As such, implementations are
> not to issue warnings, since it does not fit "such cases".

As of C++17, I agree, but that's the point of this thread: the
specification of [[nodiscard]] as of C++17 sits *in between* the actual
use cases of such an attribute. Consider:

  auto x =3D foo();
  foo(), bar();

Currently, the second line will warn, the first will not=C2=B9.

Now, if foo() returns a value that must be "used", [[nodiscard]] is not
sufficient, because *both* lines ought to warn. If it returns an RAII
wrapper, however, *neither* line should warn. What we have currently is
an attribute that has broken corner cases for both uses.

My proposal, therefore, is to split it into two attributes, *neither* of
which is precisely the same as what we have currently.

(=C2=B9 It won't warn w.r.t. [[nodiscard]], anyway, and may not warn at all=
..)

--=20
Matthew

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

.

------=_Part_2188_2053408644.1484759249311
Content-Type: multipart/alternative;
 boundary="----=_Part_2189_2061320282.1484759249311"

------=_Part_2189_2061320282.1484759249311
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 18, 2017 at 11:29:38 AM UTC-5, Matthew Woehlke wrote:
>
> On 2017-01-13 18:43, Nicol Bolas wrote:
> > On Friday, January 13, 2017 at 5:23:28 PM UTC-5, Matthew Woehlke wrote:
> >> On 2017-01-13 16:57, Nicol Bolas wrote:
> >>> Now personally, I don't think it's reasonable to detect #2. There
> >>> are too many ways to define "do something with it" for us to
> >>> catch them all. `x == x` could be considered doing something.
> >>
> >> I'm not worried about that; it is QoI for compilers to provide a
> >> reasonable definition of "do something with it".
> >
> > Absolutely not.
> >
> > The standard has a good definition of what "discard" means, so the only
> > implementation variance would be whether implementations warn on all of
> > those cases.
> >
> > By contrast, "do something with it" is decidedly nebulous. There's no
> good
> > definition of what a "quality" implementation of that would even be. Who
> is
> > to say that an implementation should warn on one thing rather than
> another?
>
> "Who" is easy: users.


> We are in any case talking about *non-normative text*.


No, we are not. [[nodiscard]] keys off of normative text: discarding
expressions. [[noreturn]] keys off of normative text. [[maybe_unusued]]
keys off of normative text. [[fallthrough]] keys off of normative text.

When the diagnostics for an attribute trigger, or don't trigger, is not a
matter of interpretation or opinion. It is a matter of standard constructs.
There should be no ambiguity or room for QoI when it comes to what
standard-defined attributes do. Implementations are allowed to ignore them,
yes. But implementations that choose not to should not arbitrarily decide
to step outside of the explicit boundaries of those attributes.

If you want to silence the warning from a [[nodiscard]] expression, there
should be absolutely no ambiguity on whether a particular syntax will
succeed at doing so. If I genuinely want to call `vector::empty()` and not
examine its return value, I should not have to alter my warnings if I do
`auto b = v.empty();`. The return value is not discarded, and therefore
[[nodiscard]]-based warnings have *absolutely no right* to complain.

*Anything else* is lying to the user.

>> This is only part of the problem. The other part is that, as I
> >> understand it, your example above:
> >>
> >>   get_lock(), do_something_while_locked();
> >>
> >> ...will trigger a warning if get_lock() is [[nodiscard]].
> >
> > That is case #3. Which I argued should be handled by its own attribute.
> > *You're* the one claiming that #1 and #3 are the same, not me.
>
> You have not sufficiently convinced me otherwise.
>
> It seems to me you want these to be handled differently:
>

No, I want a single expression to be handled differently from storing it in
a variable. Whether that variable has a name is essentially irrelevant.

Remember: I believe that case 2 is not reasonable to detect or handle due
to ambiguity, so it should be treated like case 1.


>   // case 1
>   foo() /* nodiscard */, bar();
>
>   // case 2
>   {
>     auto [] = foo(); // nodiscard
>     bar();
>   }
>
>   // case 3
>   {
>     auto [[maybe_unused]] x = foo(); // nodiscard
>     bar();
>   }
>
> ...but all of these are semantically equivalent. I don't see a
> justification for treating semantically identical code differently
> depending on how it is written.
>

But they are not identical in syntax. And therefore, there's no reason to
*expect* them to behave the same. One manifests a temporary which will be
discarded. The others create a variable. One of these should trigger
[[nodiscard]] because they discard the value. The others should not.

It's simple and based on the standard.

--
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/857027a7-8149-480c-9c88-3bb2bb9eb568%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, January 18, 2017 at 11:29:38 AM UTC-5, Matth=
ew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01-13=
 18:43, Nicol Bolas wrote:
<br>&gt; On Friday, January 13, 2017 at 5:23:28 PM UTC-5, Matthew Woehlke w=
rote:
<br>&gt;&gt; On 2017-01-13 16:57, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; Now personally, I don&#39;t think it&#39;s reasonable to d=
etect #2. There
<br>&gt;&gt;&gt; are too many ways to define &quot;do something with it&quo=
t; for us to
<br>&gt;&gt;&gt; catch them all. `x =3D=3D x` could be considered doing som=
ething.
<br>&gt;&gt;
<br>&gt;&gt; I&#39;m not worried about that; it is QoI for compilers to pro=
vide a=20
<br>&gt;&gt; reasonable definition of &quot;do something with it&quot;.
<br>&gt;=20
<br>&gt; Absolutely not.
<br>&gt;=20
<br>&gt; The standard has a good definition of what &quot;discard&quot; mea=
ns, so the only=20
<br>&gt; implementation variance would be whether implementations warn on a=
ll of=20
<br>&gt; those cases.
<br>&gt;=20
<br>&gt; By contrast, &quot;do something with it&quot; is decidedly nebulou=
s. There&#39;s no good=20
<br>&gt; definition of what a &quot;quality&quot; implementation of that wo=
uld even be. Who is=20
<br>&gt; to say that an implementation should warn on one thing rather than=
 another?
<br>
<br>&quot;Who&quot; is easy: users.</blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">
<br>We are in any case talking about *non-normative text*.</blockquote><div=
><br>No, we are not. [[nodiscard]] keys off of normative text: discarding e=
xpressions. [[noreturn]] keys off of normative text. [[maybe_unusued]] keys=
 off of normative text. [[fallthrough]] keys off of normative text.<br><br>=
When the diagnostics for an attribute trigger, or don&#39;t trigger, is not=
 a matter of interpretation or opinion. It is a matter of standard construc=
ts. There should be no ambiguity or room for QoI when it comes to what stan=
dard-defined attributes do. Implementations are allowed to ignore them, yes=
.. But implementations that choose not to should not arbitrarily decide to s=
tep outside of the explicit boundaries of those attributes.<br><br>If you w=
ant to silence the warning from a [[nodiscard]] expression, there should be=
 absolutely no ambiguity on whether a particular syntax will succeed at doi=
ng so. If I genuinely want to call `vector::empty()` and not examine its re=
turn value, I should not have to alter my warnings if I do `auto b =3D v.em=
pty();`. The return value is not discarded, and therefore [[nodiscard]]-bas=
ed warnings have <i>absolutely no right</i> to complain.<br><br><i>Anything=
 else</i> is lying to the user.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">&gt;&gt; This is only part of the problem. The other part is=
 that, as I=20
<br>&gt;&gt; understand it, your example above:=20
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 get_lock(), do_something_while_locked();=20
<br>&gt;&gt;
<br>&gt;&gt; ...will trigger a warning if get_lock() is [[nodiscard]].
<br>&gt;=20
<br>&gt; That is case #3. Which I argued should be handled by its own attri=
bute.=20
<br>&gt; *You&#39;re* the one claiming that #1 and #3 are the same, not me.
<br>
<br>You have not sufficiently convinced me otherwise.
<br>
<br>It seems to me you want these to be handled differently:<br></blockquot=
e><div><br>No, I want a single expression to be handled differently from st=
oring it in a variable. Whether that variable has a name is essentially irr=
elevant.<br><br>Remember: I believe that case 2 is not reasonable to detect=
 or handle due to ambiguity, so it should be treated like case 1.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>=C2=A0 // case 1
<br>=C2=A0 foo() /* nodiscard */, bar();
<br>
<br>=C2=A0 // case 2
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 auto [] =3D foo(); // nodiscard
<br>=C2=A0 =C2=A0 bar();
<br>=C2=A0 }
<br>
<br>=C2=A0 // case 3
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 auto [[maybe_unused]] x =3D foo(); // nodiscard
<br>=C2=A0 =C2=A0 bar();
<br>=C2=A0 }
<br>
<br>...but all of these are semantically equivalent. I don&#39;t see a
<br>justification for treating semantically identical code differently
<br>depending on how it is written.<br></blockquote><div><br></div>But they=
 are not identical in syntax. And therefore, there&#39;s no reason to <i>ex=
pect</i> them to behave the same. One manifests a temporary which will be d=
iscarded. The others create a variable. One of these should trigger [[nodis=
card]] because they discard the value. The others should not.<br><br>It&#39=
;s simple and based on the standard.<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/857027a7-8149-480c-9c88-3bb2bb9eb568%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/857027a7-8149-480c-9c88-3bb2bb9eb568=
%40isocpp.org</a>.<br />

------=_Part_2189_2061320282.1484759249311--

------=_Part_2188_2053408644.1484759249311--

.

On 2017-01-18 12:07, Nicol Bolas wrote:
> On Wednesday, January 18, 2017 at 11:29:38 AM UTC-5, Matthew Woehlke wrote:
>> We are in any case talking about *non-normative text*.
>
> No, we are not. [[nodiscard]] keys off of normative text: discarding
> expressions.
>
> When the diagnostics for an attribute trigger, or don't trigger, is not a
> matter of interpretation or opinion.

Did you even *read* Ville's posts?

In particular, you apparently have an interesting definition of the word
"encouraged" as it is used in the standard. One that is not shared by
anyone else TTBOMK.

I suppose you will next argue that all compiler warnings - at least
those for "this is valid code, but *probably* not what you want" - are
non-conforming.

>> It seems to me you want these to be handled differently:
>> [examples are below]
>
> No, I want a single expression to be handled differently from storing it in
> a variable. Whether that variable has a name is essentially irrelevant.

Well, then all I can do then is strongly disagree with you, because I
find that behavior completely and utterly broken. IMO the distinction
you don't care about is the very distinction that matters. Either it is
okay if I don't ever "look at" the result, as long as it isn't
immediately destroyed (RAII), or I really need to "look at" it for my
code to make sense (vector::empty()).

> Remember: I believe that case 2 is not reasonable to detect

I continue to be utterly baffled as to why you feel this way,
considering that *compilers already detect it!* Why you should want us
to regress here is beyond me.

>>   // case 1
>>   foo() /* nodiscard */, bar();
>>
>>   // case 2
>>   {
>>     auto [] = foo(); // nodiscard
>>     bar();
>>   }
>>
>>   // case 3
>>   {
>>     auto [[maybe_unused]] x = foo(); // nodiscard
>>     bar();
>>   }
>>
>> ...but all of these are semantically equivalent. I don't see a
>> justification for treating semantically identical code differently
>> depending on how it is written.
>
> But they are not identical in syntax. And therefore, there's no reason to
> *expect* them to behave the same. One manifests a temporary which will be
> discarded. The others create a variable. One of these should trigger
> [[nodiscard]] because they discard the value. The others should not.

You are creating a false dichotomy. *All three* manifest a temporary
that remains in scope until `bar()` has executed. The third happens to
assign that temporary a name, which could allow it to be subsequently
accessed, but no such access occurs.

--
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/587FB2BF.50607%40gmail.com.

.

On 18 January 2017 at 19:07, Nicol Bolas <jmckesson@gmail.com> wrote:
> There should be no ambiguity or room for QoI when it comes to what
> standard-defined attributes do. Implementations are allowed to ignore them,

It's completely a matter of QoI, that's what the specification says.

> If you want to silence the warning from a [[nodiscard]] expression, there
> should be absolutely no ambiguity on whether a particular syntax will
> succeed at doing so. If I genuinely want to call `vector::empty()` and not
> examine its return value, I should not have to alter my warnings if I do
> `auto b = v.empty();`. The return value is not discarded, and therefore
> [[nodiscard]]-based warnings have absolutely no right to complain.

An implementation is allowed to issue diagnostics that the standard mandate
for any reasons it pleases. An implementation can tell you that member variable
names must be mPrefixedFunnyCamels, and an implementation can tell
you that auto b = v.empty() is not a sufficient way to silence a
nodiscard-attribute-diagnostic
based on your local style guide. The standard doesn't prevent any of that.
The standard provides non-normative encouragement. That isn't guaranteed to have
a particular impact on an implementation; it's not guaranteed to have
*any* impact
on an implementation. There's a difference between what you want, what
you think the
standard should specify, and what the standard actually specifies, at
least based on what
you seem to be stating above.

> Anything else is lying to the user.

Which, like it or not, is a QoI matter, and some of the things I
mention above would be perfectly valid,
but yet "lying to the user" according to your definition of 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/CAFk2RUaQgifTWf38bWzU8dFy2rkxH%3DF2ZiM%3DGk4OQ-QAoHfMTg%40mail.gmail.com.

.

------=_Part_821_692564557.1484770395156
Content-Type: multipart/alternative;
 boundary="----=_Part_822_324106179.1484770395156"

------=_Part_822_324106179.1484770395156
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 18, 2017 at 1:24:04 PM UTC-5, Matthew Woehlke wrote:
>
> On 2017-01-18 12:07, Nicol Bolas wrote:
> > On Wednesday, January 18, 2017 at 11:29:38 AM UTC-5, Matthew Woehlke
> wrote:
> >> We are in any case talking about *non-normative text*.
> >
> > No, we are not. [[nodiscard]] keys off of normative text: discarding
> > expressions.
> >
> > When the diagnostics for an attribute trigger, or don't trigger, is not
> a
> > matter of interpretation or opinion.
>
> Did you even *read* Ville's posts?
>
> In particular, you apparently have an interesting definition of the word
> "encouraged" as it is used in the standard. One that is not shared by
> anyone else TTBOMK.
>
> I suppose you will next argue that all compiler warnings - at least
> those for "this is valid code, but *probably* not what you want" - are
> non-conforming.
>
> >> It seems to me you want these to be handled differently:
> >> [examples are below]
> >
> > No, I want a single expression to be handled differently from storing it
> in
> > a variable. Whether that variable has a name is essentially irrelevant.
>
> Well, then all I can do then is strongly disagree with you, because I
> find that behavior completely and utterly broken. IMO the distinction
> you don't care about is the very distinction that matters. Either it is
> okay if I don't ever "look at" the result, as long as it isn't
> immediately destroyed (RAII), or I really need to "look at" it for my
> code to make sense (vector::empty()).
>
> > Remember: I believe that case 2 is not reasonable to detect
>
> I continue to be utterly baffled as to why you feel this way,
> considering that *compilers already detect it!*


But not *correctly*. They can detect that you've done something with the
variable. But they cannot detect that you've done the *right thing*.

For example, `v.empty() == false;`, as a complete statement, is clearly not
discarding the value. But it is also not really "doing something" with it,
not in any meaningful way. You used it in an expression, but at the same
time, it's not accomplishing anything. Similarly, `if(v.empty());` is not
discarding the value in accord with the standard, but it's also not "doing
something" with it.

The question of how much "something" should be done is not one that can be
answered. And the reason it cannot be answered is because, sometimes, you
*want* to discard something that was labeled [[nodiscard]]. Therefore,
there *must* be a way to tell the compiler to shut up.

So in a "quality" implementation, `bool b = v.empty()` ought to be
sufficient to get the compiler not to complain about discarding a
[[nodiscard]] statement. If there can be no syntax that a user can *rely on*
to stop these warnings when they explicitly want to discard such a value,
then the feature is not useful.

That syntax should not be developed by convention or by "quality of
implementation". It should be set down in the standard the way it is now.
If an expression is [[nodiscard]] and you discard it, you get a warning. If
you do something that ignores the value but is not "discarding" it, you
should not get a warning.

Anything else is wrong.

Why you should want us
> to regress here is beyond me.
>
> >>   // case 1
> >>   foo() /* nodiscard */, bar();
> >>
> >>   // case 2
> >>   {
> >>     auto [] = foo(); // nodiscard
> >>     bar();
> >>   }
> >>
> >>   // case 3
> >>   {
> >>     auto [[maybe_unused]] x = foo(); // nodiscard
> >>     bar();
> >>   }
> >>
> >> ...but all of these are semantically equivalent. I don't see a
> >> justification for treating semantically identical code differently
> >> depending on how it is written.
> >
> > But they are not identical in syntax. And therefore, there's no reason
> to
> > *expect* them to behave the same. One manifests a temporary which will
> be
> > discarded. The others create a variable. One of these should trigger
> > [[nodiscard]] because they discard the value. The others should not.
>
> You are creating a false dichotomy. *All three* manifest a temporary
> that remains in scope until `bar()` has executed. The third happens to
> assign that temporary a name, which could allow it to be subsequently
> accessed, but no such access occurs.
>

I used very careful wording there for a reason. The term "manifest a
temporary" applies *only* to taking a prvalue and making a temporary out of
it. It's part of C++17's guaranteed elision. A prvalue alone doesn't mean
that there's a temporary; it's how the prvalue gets used that manifests a
temporary or not. If you use a prvalue to assign to a variable of the
prvalue's type, then no temporary is manifested.

It sounds like a subtle distinction, but it's what allows guaranteed
elision to work. And therefore, it is what makes different syntax mean
different things.

--
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/787c1aaf-33a6-473b-b433-a0d6ed129a7f%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, January 18, 2017 at 1:24:04 PM UTC-5, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-01-18 =
12:07, Nicol Bolas wrote:
<br>&gt; On Wednesday, January 18, 2017 at 11:29:38 AM UTC-5, Matthew Woehl=
ke wrote:
<br>&gt;&gt; We are in any case talking about *non-normative text*.
<br>&gt;=20
<br>&gt; No, we are not. [[nodiscard]] keys off of normative text: discardi=
ng=20
<br>&gt; expressions.
<br>&gt;
<br>&gt; When the diagnostics for an attribute trigger, or don&#39;t trigge=
r, is not a=20
<br>&gt; matter of interpretation or opinion.
<br>
<br>Did you even *read* Ville&#39;s posts?
<br>
<br>In particular, you apparently have an interesting definition of the wor=
d
<br>&quot;encouraged&quot; as it is used in the standard. One that is not s=
hared by
<br>anyone else TTBOMK.
<br>
<br>I suppose you will next argue that all compiler warnings - at least
<br>those for &quot;this is valid code, but *probably* not what you want&qu=
ot; - are
<br>non-conforming.
<br>
<br>&gt;&gt; It seems to me you want these to be handled differently:
<br>&gt;&gt; [examples are below]
<br>&gt;=20
<br>&gt; No, I want a single expression to be handled differently from stor=
ing it in=20
<br>&gt; a variable. Whether that variable has a name is essentially irrele=
vant.
<br>
<br>Well, then all I can do then is strongly disagree with you, because I
<br>find that behavior completely and utterly broken. IMO the distinction
<br>you don&#39;t care about is the very distinction that matters. Either i=
t is
<br>okay if I don&#39;t ever &quot;look at&quot; the result, as long as it =
isn&#39;t
<br>immediately destroyed (RAII), or I really need to &quot;look at&quot; i=
t for my
<br>code to make sense (vector::empty()).
<br>
<br>&gt; Remember: I believe that case 2 is not reasonable to detect
<br>
<br>I continue to be utterly baffled as to why you feel this way,
<br>considering that *compilers already detect it!*</blockquote><div><br>Bu=
t not <i>correctly</i>. They can detect that you&#39;ve done something with=
 the variable. But they cannot detect that you&#39;ve done the <i>right thi=
ng</i>.<br><br>For example, `v.empty() =3D=3D false;`, as a complete statem=
ent, is clearly not discarding the value. But it is also not really &quot;d=
oing something&quot; with it, not in any meaningful way. You used it in an =
expression, but at the same time, it&#39;s not accomplishing anything. Simi=
larly, `if(v.empty());` is not discarding the value in accord with the stan=
dard, but it&#39;s also not &quot;doing something&quot; with it.<br><br>The=
 question of how much &quot;something&quot; should be done is not one that =
can be answered. And the reason it cannot be answered is because, sometimes=
, you <i>want</i> to discard something that was labeled [[nodiscard]]. Ther=
efore, there <i>must</i> be a way to tell the compiler to shut up.<br><br>S=
o in a &quot;quality&quot; implementation, `bool b =3D v.empty()` ought to =
be sufficient to get the compiler not to complain about discarding a [[nodi=
scard]] statement. If there can be no syntax that a user can <i>rely on</i>=
 to stop these warnings when they explicitly want to discard such a value, =
then the feature is not useful.<br><br>That syntax should not be developed =
by convention or by &quot;quality of implementation&quot;. It should be set=
 down in the standard the way it is now. If an expression is [[nodiscard]] =
and you discard it, you get a warning. If you do something that ignores the=
 value but is not &quot;discarding&quot; it, you should not get a warning.<=
br><br>Anything else is wrong.<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">Why you should want us
<br>to regress here is beyond me.
<br>
<br>&gt;&gt; =C2=A0 // case 1=20
<br>&gt;&gt; =C2=A0 foo() /* nodiscard */, bar();=20
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 // case 2=20
<br>&gt;&gt; =C2=A0 {=20
<br>&gt;&gt; =C2=A0 =C2=A0 auto [] =3D foo(); // nodiscard=20
<br>&gt;&gt; =C2=A0 =C2=A0 bar();=20
<br>&gt;&gt; =C2=A0 }=20
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 // case 3=20
<br>&gt;&gt; =C2=A0 {=20
<br>&gt;&gt; =C2=A0 =C2=A0 auto [[maybe_unused]] x =3D foo(); // nodiscard=
=20
<br>&gt;&gt; =C2=A0 =C2=A0 bar();=20
<br>&gt;&gt; =C2=A0 }=20
<br>&gt;&gt;
<br>&gt;&gt; ...but all of these are semantically equivalent. I don&#39;t s=
ee a=20
<br>&gt;&gt; justification for treating semantically identical code differe=
ntly=20
<br>&gt;&gt; depending on how it is written.
<br>&gt;=20
<br>&gt; But they are not identical in syntax. And therefore, there&#39;s n=
o reason to=20
<br>&gt; *expect* them to behave the same. One manifests a temporary which =
will be=20
<br>&gt; discarded. The others create a variable. One of these should trigg=
er=20
<br>&gt; [[nodiscard]] because they discard the value. The others should no=
t.
<br>
<br>You are creating a false dichotomy. *All three* manifest a temporary
<br>that remains in scope until `bar()` has executed. The third happens to
<br>assign that temporary a name, which could allow it to be subsequently
<br>accessed, but no such access occurs.<br></blockquote><div><br>I used ve=
ry careful wording there for a reason. The term &quot;manifest a temporary&=
quot; applies <i>only</i> to taking a prvalue and making a temporary out of=
 it. It&#39;s part of C++17&#39;s guaranteed elision. A prvalue alone doesn=
&#39;t mean that there&#39;s a temporary; it&#39;s how the prvalue gets use=
d that manifests a temporary or not. If you use a prvalue to assign to a va=
riable of the prvalue&#39;s type, then no temporary is manifested.<br><br>I=
t sounds like a subtle distinction, but it&#39;s what allows guaranteed eli=
sion to work. And therefore, it is what makes different syntax mean differe=
nt things.<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/787c1aaf-33a6-473b-b433-a0d6ed129a7f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/787c1aaf-33a6-473b-b433-a0d6ed129a7f=
%40isocpp.org</a>.<br />

------=_Part_822_324106179.1484770395156--

------=_Part_821_692564557.1484770395156--

.

------=_Part_3155_1831146458.1484770908410
Content-Type: multipart/alternative;
 boundary="----=_Part_3156_1245564867.1484770908410"

------=_Part_3156_1245564867.1484770908410
Content-Type: text/plain; charset=UTF-8



On Wednesday, January 18, 2017 at 1:43:11 PM UTC-5, Ville Voutilainen wrote:
>
> On 18 January 2017 at 19:07, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > There should be no ambiguity or room for QoI when it comes to what
> > standard-defined attributes do. Implementations are allowed to ignore
> them,
>
> It's completely a matter of QoI, that's what the specification says.
>
> > If you want to silence the warning from a [[nodiscard]] expression,
> there
> > should be absolutely no ambiguity on whether a particular syntax will
> > succeed at doing so. If I genuinely want to call `vector::empty()` and
> not
> > examine its return value, I should not have to alter my warnings if I do
> > `auto b = v.empty();`. The return value is not discarded, and therefore
> > [[nodiscard]]-based warnings have absolutely no right to complain.
>
> An implementation is allowed to issue diagnostics that the standard
> mandate
> for any reasons it pleases. An implementation can tell you that member
> variable
> names must be mPrefixedFunnyCamels, and an implementation can tell
> you that auto b = v.empty() is not a sufficient way to silence a
> nodiscard-attribute-diagnostic
> based on your local style guide.


Then we should *never* apply [[nodiscard]] to anything in the standard
library.

If compiler vendors are going to do non-obvious things, if there isn't an
obvious way to tell the compiler to shut up that all vendors will
implement, then we have no right to force users to listen to its advice.

--
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/0c5ded8b-ad02-45f7-b754-344f2f5cfc33%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, January 18, 2017 at 1:43:11 PM UTC-5=
, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 1=
8 January 2017 at 19:07, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"gl8M3NRxCAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; There should be no ambiguity or room for QoI when it comes to what
<br>&gt; standard-defined attributes do. Implementations are allowed to ign=
ore them,
<br>
<br>It&#39;s completely a matter of QoI, that&#39;s what the specification =
says.
<br>
<br>&gt; If you want to silence the warning from a [[nodiscard]] expression=
, there
<br>&gt; should be absolutely no ambiguity on whether a particular syntax w=
ill
<br>&gt; succeed at doing so. If I genuinely want to call `vector::empty()`=
 and not
<br>&gt; examine its return value, I should not have to alter my warnings i=
f I do
<br>&gt; `auto b =3D v.empty();`. The return value is not discarded, and th=
erefore
<br>&gt; [[nodiscard]]-based warnings have absolutely no right to complain.
<br>
<br>An implementation is allowed to issue diagnostics that the standard man=
date
<br>for any reasons it pleases. An implementation can tell you that member =
variable
<br>names must be mPrefixedFunnyCamels, and an implementation can tell
<br>you that auto b =3D v.empty() is not a sufficient way to silence a
<br>nodiscard-attribute-diagnostic
<br>based on your local style guide.</blockquote><div><br>Then we should <i=
>never</i> apply [[nodiscard]] to anything in the standard library.<br><br>=
If compiler vendors are going to do non-obvious things, if there isn&#39;t =
an obvious way to tell the compiler to shut up that all vendors will implem=
ent, then we have no right to force users to listen to its advice.</div></d=
iv>

<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/0c5ded8b-ad02-45f7-b754-344f2f5cfc33%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c5ded8b-ad02-45f7-b754-344f2f5cfc33=
%40isocpp.org</a>.<br />

------=_Part_3156_1245564867.1484770908410--

------=_Part_3155_1831146458.1484770908410--

.

On 18 January 2017 at 22:21, Nicol Bolas <jmckesson@gmail.com> wrote:
> Then we should never apply [[nodiscard]] to anything in the standard
> library.
>
> If compiler vendors are going to do non-obvious things, if there isn't an
> obvious way to tell the compiler to shut up that all vendors will implement,
> then we have no right to force users to listen to its advice.


I don't know where you took the conjecture "compiler vendors are going
to do non-obvious things"
from, but there is no way to portably silence any diagnostic,
regardless of [[nodiscard]]. The
lack of that guarantee doesn't constitute a reason to never apply a
standard attribute in the library,
as far as I'm concerned.

--
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/CAFk2RUYF%2BYXah-w%2BcpzCvnxe%3DYbxV8aBkgJiKaymdNoieaVAyw%40mail.gmail.com.

.

On 2017-01-18 15:13, Nicol Bolas wrote:
> On Wednesday, January 18, 2017 at 1:24:04 PM UTC-5, Matthew Woehlke wrote:
>> I continue to be utterly baffled as to why you feel this way,
>> considering that *compilers already detect it!*
>
> But not *correctly*. They can detect that you've done something with the
> variable. But they cannot detect that you've done the *right thing*.
>
> For example, `v.empty() == false;`, as a complete statement, is clearly not
> discarding the value.

From a non-standardese POV, I'd dispute that, especially as the compiler
knows that operator== here has no side effects. Still, it would be hard
to write such a statement by accident.

Actually, this inspires a potential phrasing for when the compiler
should warn: if the value is not used in a way that causes side effects,
exclusive of any side effects resulting directly from the value's
destruction.

> Similarly, `if(v.empty());` is not discarding the value in accord
> with the standard, but it's also not "doing something" with it.

On the contrary, I would consider this a perfectly reasonable use of the
return value; you used it in a conditional.

Yes, that statement is broken because the `if` has no body (I'm assuming
it also was not followed by `else`), but that's something the compiler
should warn about on its own merits, totally unrelated to `::empty()`
being `[[nodiscard]]` (or whatever).

> The question of how much "something" should be done is not one that can be
> answered. And the reason it cannot be answered is because, sometimes, you
> *want* to discard something that was labeled [[nodiscard]]. Therefore,
> there *must* be a way to tell the compiler to shut up.

....and *we already have that*: either `[[maybe_unused]]`, or an explicit
cast-to-void. (The latter is even included in the recommendation of how
to handle `[[nodiscard]]`.) The advantage of these is that they are hard
to employ by accident, and more clearly note the intention that the
value is not used.

Assigning a `[[nodiscard]]` result to a variable could easily happen by
mistake (or misunderstanding of the API) because the user confused a
value that needs to be inspected for one that just needs to remain in
scope for a while.

--
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/587FD6B9.1090203%40gmail.com.

.

------=_Part_1466_252644909.1484773303266
Content-Type: multipart/alternative;
 boundary="----=_Part_1467_7744588.1484773303267"

------=_Part_1467_7744588.1484773303267
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 18, 2017 at 3:42:07 PM UTC-5, Ville Voutilainen wrote:
>
> On 18 January 2017 at 22:21, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > Then we should never apply [[nodiscard]] to anything in the standard
> > library.
> >
> > If compiler vendors are going to do non-obvious things, if there isn't
> an
> > obvious way to tell the compiler to shut up that all vendors will
> implement,
> > then we have no right to force users to listen to its advice.
>
>
> I don't know where you took the conjecture "compiler vendors are going
> to do non-obvious things"
> from, but there is no way to portably silence any diagnostic,
> regardless of [[nodiscard]]. The
> lack of that guarantee doesn't constitute a reason to never apply a
> standard attribute in the library,
> as far as I'm concerned.
>

We can't have people suffer through spurious warnings because of compilers
that are doing things that they think are "reasonable", because of "quality
implementation". So if we users cannot genuinely rely on compiler vendors
doing the right thing with such an attribute, then we must not force such
attributes upon them.

Yes, the standard cannot formally make it impossible for a compiler to
implement such a warning when you discard-but-ignore a [[nodiscard]]
expression. But if we're even considering the possiblity that a compiler
vendor will think that warning over `auto b = v.empty();` due to the
presence of [[nodiscard]], then that's a problem.

I'm saying the recommendation in the standard should be that [[nodiscard]]
should *only* provoke a diagnostic in cases where the expression value was
discarded, in accord with the standard meaning of that term. It should
*explicitly* recommend that implementations *not* issue a diagnostic if the
value is not discarded but is otherwise ignored.

--
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/1854b84b-92c0-48b0-999e-4b0bca0423e0%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, January 18, 2017 at 3:42:07 PM UTC-5, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 Januar=
y 2017 at 22:21, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"rG7e8_1OAAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; Then we should never apply [[nodiscard]] to anything in the standa=
rd
<br>&gt; library.
<br>&gt;
<br>&gt; If compiler vendors are going to do non-obvious things, if there i=
sn&#39;t an
<br>&gt; obvious way to tell the compiler to shut up that all vendors will =
implement,
<br>&gt; then we have no right to force users to listen to its advice.
<br>
<br>
<br>I don&#39;t know where you took the conjecture &quot;compiler vendors a=
re going
<br>to do non-obvious things&quot;
<br>from, but there is no way to portably silence any diagnostic,
<br>regardless of [[nodiscard]]. The
<br>lack of that guarantee doesn&#39;t constitute a reason to never apply a
<br>standard attribute in the library,
<br>as far as I&#39;m concerned.<br></blockquote><div><br>We can&#39;t have=
 people suffer through spurious warnings because of compilers that are doin=
g things that they think are &quot;reasonable&quot;, because of &quot;quali=
ty implementation&quot;. So if we users cannot genuinely rely on compiler v=
endors doing the right thing with such an attribute, then we must not force=
 such attributes upon them.<br><br>Yes, the standard cannot formally make i=
t impossible for a compiler to implement such a warning when you discard-bu=
t-ignore a [[nodiscard]] expression. But if we&#39;re even considering the =
possiblity that a compiler vendor will think that warning over `auto b =3D =
v.empty();` due to the presence of [[nodiscard]], then that&#39;s a problem=
..<br><br>I&#39;m saying the recommendation in the standard should be that [=
[nodiscard]] should <i>only</i> provoke a diagnostic in cases where the exp=
ression value was discarded, in accord with the standard meaning of that te=
rm. It should <i>explicitly</i> recommend that implementations <i>not</i> i=
ssue a diagnostic if the value is not discarded but is otherwise ignored.<b=
r></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/1854b84b-92c0-48b0-999e-4b0bca0423e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1854b84b-92c0-48b0-999e-4b0bca0423e0=
%40isocpp.org</a>.<br />

------=_Part_1467_7744588.1484773303267--

------=_Part_1466_252644909.1484773303266--

.

On 18 January 2017 at 23:01, Nicol Bolas <jmckesson@gmail.com> wrote:
> We can't have people suffer through spurious warnings because of compilers
> that are doing things that they think are "reasonable", because of "quality

We already have people "suffering" from that, and it seems that people aren't
complaining, because implementation vendors either provide reasonable
diagnostics
by default or allow users to control the diagnostics (including
turning them off) via
various implementation-specific means.

> implementation". So if we users cannot genuinely rely on compiler vendors
> doing the right thing with such an attribute, then we must not force such
> attributes upon them.

Hypothetical.

> I'm saying the recommendation in the standard should be that [[nodiscard]]
> should only provoke a diagnostic in cases where the expression value was
> discarded, in accord with the standard meaning of that term. It should
> explicitly recommend that implementations not issue a diagnostic if the
> value is not discarded but is otherwise ignored.

Compiler vendors aren't idiots, they don't need their hands held in such detail,
and such a recommendation is still as non-normative as any recommendation
on any attribute; it has no normative power nor does it have any conformance
effect, and nobody is complaining about that, with the possible
exception of you. :)

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

.

On 2017-01-18 16:01, Nicol Bolas wrote:
> I'm saying the recommendation in the standard should be that [[nodiscard]]
> should *only* provoke a diagnostic in cases where the expression value was
> discarded, in accord with the standard meaning of that term. It should
> *explicitly* recommend that implementations *not* issue a diagnostic if the
> value is not discarded but is otherwise ignored.

While we're at it, let's recommend that none of the following issue any
warnings:

  if (a = b) { ... } // you meant '=='
  { int x = 5; } // unused variable
  int foo() {} // missing 'return'
  const int bar(); // 'const' is ignored
  int foo() { int x; return x; } // uninitialized value used
  if (a <= b <= c) // LAAEFTR

....because obviously compilers shouldn't warn about things that are
legal but almost certainly wrong.

</irony>

Such low confidence you have in compiler vendors...

On 2017-01-18 16:05, Ville Voutilainen wrote:
> nobody is complaining about that, with the possible exception of you.

Amen! :-)

--
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/587FDED8.8050201%40gmail.com.

.