C++17 feature proposal: Allow [[maybe_unused]]

[Avi Drissman]

Just like [[nodiscard]] is WARN_UNUSED_RESULT, [[maybe_unused]] is our ignore_result.

I propose allowing [[maybe_unused]], migrating all uses of ignore_result to use it, and killing off base/ignore_result.h.

Avi

[Łukasz Anforowicz]

FWIW std::ignore has been present since C++11

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAYfOo_xBXLQfvt%2B3WE4k%2B2rcPHxFGn6MHf6QX6kVFRrQQ%40mail.gmail.com.

[Avi Drissman]

std::ignore is intended for use in std::tie, and while it could be used to silence nodiscard warnings, maybe_unused is better and handles more circumstances.

We could call that out in the use instructions, that maybe_unused is preferred for that purpose.

[Peter Kasting]

+1

PK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAa-bHf%2BCa7M6eCzgk-K4EHGBdeUL5rd%3D2f%2B52UD42MFVw%40mail.gmail.com.

[Roland McGrath]

What are the disadvantages and unhandled circumstances of std::ignore?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAa-bHf%2BCa7M6eCzgk-K4EHGBdeUL5rd%3D2f%2B52UD42MFVw%40mail.gmail.com.

[dan...@chromium.org]

+1

--

[Avi Drissman]

std::ignore is basically a /dev/null for values. You can assign any value into it. I don't know what the rules are for the generated code. It can be used to quiet [[nodiscard]] warnings, but only for functions that return a value.

[[maybe_unused]] is a lot more powerful. It can silence any unused warning, even in the cases of an unused function or enumerator or variable where std::ignore wouldn't work. It's better because it's a way to express exactly what you mean. If you mean "don't warn me about not having used this", then you should use the annotation that says "don't warn me", not use the feature that adds a no-op use to make the thing not be unused.

I wouldn't ban the use of std::ignore for silencing warnings, but the guidance in the file would be to use ignore for tie, and the annotation for warnings.

Avi

[Avi Drissman]

OK, I completely misunderstood all of this. Let me try again.

We warn for unused code, and [[maybe_unused]] can be used to stop that warning. I don't know if it's useful for us right now, but probably worth accepting.

[[maybe_unused]] cannot be used instead of ignore_result, no matter what it says in c++11.md. We would need to use std::ignore for that, and I'm happy to run the LSC to kill ignore_result, though that's off-topic for this thread.

[Roland McGrath]

The common case I'm aware of for [[maybe_unused]] is a variable or function that's only referenced in an assertion or other form of conditional compilation.  In the cases where the compiler would complain about it being unused, the compiler will also optimize it out, so suppressing the complaint is usually easier than duplicating all the conditionalization to explicitly avoid compiling it.

[Avi Drissman]

Do you know of any specific cases today that we have in the code? That would help in getting it accepted.

[Roland McGrath]

I do not.  Places where it would be good to use it likely manifest as some code being under some extra `#if` conditions that make it a little unsightly, but I doubt that will be very easy to search for.

[dan...@chromium.org]

On Thu, Jan 6, 2022 at 4:57 PM 'Avi Drissman' via cxx <c...@chromium.org> wrote:

Do you know of any specific cases today that we have in the code? That would help in getting it accepted.

It can be used in place of `(void)foo`;

int foo = 2;

(void)foo;

vs

[[maybe_unused]] int foo = 2;

Where `foo` is conditionally used depending on the compile mode.

 

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAbdnioNRR46KEBNi8wcipYSmZV2nN5qpC3d%2BZa1rWEiMQ%40mail.gmail.com.

[Avi Drissman]

Do you know of any cases in the code which could be used as an exemplar here?

[Avi Drissman]

OK, I think I have an exemplar. Proposed CL forthcoming.

[Peter Kasting]

On Thu, Jan 6, 2022 at 3:25 PM <dan...@chromium.org> wrote:

On Thu, Jan 6, 2022 at 4:57 PM 'Avi Drissman' via cxx <c...@chromium.org> wrote:

Do you know of any specific cases today that we have in the code? That would help in getting it accepted.

It can be used in place of `(void)foo`;

int foo = 2;

(void)foo;

vs

[[maybe_unused]] int foo = 2;

Where `foo` is conditionally used depending on the compile mode.

This is our ALLOW_UNUSED_LOCAL.

PK 

[Avi Drissman]

Ah! Yes. The proposal then is to replace ALLOW_UNUSED_LOCAL with this.

[Avi Drissman]

And ALLOW_UNUSED_TYPE.

[Avi Drissman]

Official proposal:

- Allow [[maybe_unused]]

- Migrate all uses of ALLOW_UNUSED_LOCAL and ALLOW_UNUSED_TYPE to use [[maybe_unused]] and remove those macros

CL to kick this off is https://crrev.com/c/3370528. If approved I'll file a bug for the migration.

[Avi Drissman]

A fresh Monday morning ping.

My proposal is to allow [[maybe_unused]], and to convert ALLOW_UNUSED_LOCAL, ALLOW_UNUSED_TYPE, and __attribute__((unused)). Will file a bug for the conversion.

The kickoff CL is https://crrev.com/c/3370528, and a WIP CL in which I was experimenting with more removal is https://crrev.com/c/3375182. Please let me know what you think.

[Peter Kasting]

+1

[dan...@chromium.org]

LGTM

--

You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAake--rvdeZAMxbqpnYf0Zupji51Y0FqfxLU1rv-muiag%40mail.gmail.com.