Migrating ignore_result to std::ignore

123 views
Skip to first unread message

Avi Drissman

unread,
Jan 6, 2022, 4:57:02 PM1/6/22
to cxx
A proposed LSC. I want to run it by you folks first.

We have ignore_result. As part of std::tie in C++11, std::ignore was added, which basically acts as a /dev/null to throw results into.

The only hesitation that I have for doing a LSC for moving to std::ignore is that it lives in <tuple> which is a weird include, TBH. However, that's where std::ignore lives, that's not changing, and moving to a standard function and deleting our own is always a good thing.

Any objections before I propose this?

Avi

Avi Drissman

unread,
Jan 6, 2022, 5:09:16 PM1/6/22
to cxx
There are only ~750 uses. Filed as https://crbug.com/1285085, it should be doable without an official LSC.

Avi Drissman

unread,
Jan 10, 2022, 4:55:52 PM1/10/22
to cxx
Daniel raised an interesting question as to whether this is the right thing.

Right now we have WARN_UNUSED_RESULT which today is __attribute__((warn_unused_result)) and tomorrow will likely be [[nodiscard]]. To cancel it, today we have ignore_result().

Daniel points to
which say that the preferred way to cancel a [[nodiscard]] is a (void) cast. He notes that https://google.github.io/styleguide/cppguide.html#Casting was specifically updated to allow C-style casts to void, although the style guide doesn't give explicit guidance here.

I was going from the silence here, but also from https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-casts which explicitly says to use std::ignore in this case:

Never cast to (void) to ignore a [[nodiscard]] return value. If you deliberately want to discard such a result, first think hard about whether that is really a good idea (there is usually a good reason the author of the function or of the return type used [[nodiscard]] in the first place). If you still think it’s appropriate and your code reviewer agrees, use std::ignore = to turn off the warning which is simple, portable, and easy to grep.

Thoughts?

Avi

K. Moon

unread,
Jan 10, 2022, 5:36:00 PM1/10/22
to Avi Drissman, cxx
I'm fine with either, and probably would prefer std::ignore if that's what's more common in the wider C++ community.

I'm guessing the guidance to use std::ignore is motivated by the fact that this is a guideline about avoiding casting. The grep friendliness seems about the same for code bases that don't use (void) for other purposes (probably Chromium), although not for C/C++ code bases in general. (void) doesn't require including <tuple>, which is a nice point in its favor. I don't think any of these points are decisive.

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

Avi Drissman

unread,
Jan 11, 2022, 12:59:25 PM1/11/22
to K. Moon, cxx
I'm happy to go either way, and I'm happy to revise my earlier patches to (void) if that's the way we go.

However, as a public open-source project we have no guidance. The two links that explicitly say (void) are Google-only (I just realized that I posted those links on this list, sorry) and are not useful external guidance. The internal style arbiters allowed for (void) in the style guide but did not explicitly say that that's how you should bypass the use requirements of [[nodiscard]]. If they want to add that note to the style guide, I'd definitely see that as a definitive source for making a change.

Otherwise, I'm not sure how to proceed.

Avi

dan...@chromium.org

unread,
Jan 11, 2022, 1:08:26 PM1/11/22
to Avi Drissman, K. Moon, cxx
A rubric:

- If we started the project new today, what would we use?

I think std::ignore?

- What is the cost of banning and not the standard type?

A bit of local team knowledge to use a base thing.

- What is the cost of converting from the base thing to the standard type? How feasible is it?

Simple  and feasible given the number of uses, I believe we will remove the base type without issue.

To me, I think that points to using std::ignore. Even though I don't like it personally more than (void), I don't think anyone would think to write ignore_result() in //base to replace it, if starting new today.

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

Avi Drissman

unread,
Jan 11, 2022, 1:24:49 PM1/11/22
to Dana Jansens, K. Moon, cxx
I agree that ignore_result() needs to go.

(void) vs std::ignore is the question for me. I have external guidance towards one, and internal guidance towards another. The internal guidance is not authoritative for us as an open-source project, and the external guidance is from the ISO C++ folks, which is pretty authoritative.

If the Google C++ style guide said explicitly to use (void) in this case (instead of merely permitting a C-style void cast), it would clearly be the authority to follow in Chromium. If someone wants to make that happen, please do so! I'll put my migration on pause and will change the migration that I'm doing to use (void).

However, if not, I'll continue with my use of std::ignore.

Avi

Mark Mentovai

unread,
Jan 11, 2022, 1:30:39 PM1/11/22
to Avi Drissman, Dana Jansens, K. Moon, cxx
Reading a bit more into the internal discussion comparing (void) and std::ignore, it seems that the concern with std::ignore was that it was only specified for use with std::tie. I believe that this has been broadened (or interpreted more broadly), at least by authoritative-enough references like this one Avi cites, if not by the standard itself (no time to check right now). This is compelling enough for me to overcome the specific concern about std::ignore being unsuitable. I am in favor of std::ignore and, in fact, never much cared for the more obscure (void), which I see as an obtuse overload. In fact, if the only standard option available were (void), I would oppose any migration, and favor retaining ignore_result.

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

K. Moon

unread,
Jan 11, 2022, 1:47:10 PM1/11/22
to Mark Mentovai, Avi Drissman, Dana Jansens, cxx
I strongly dislike ignore_result, and would prefer anything over it. 🙂

ABSL_MUST_USE_RESULT mentions cast-to-void in its documentation, but I don't think that's a strong endorsement. I don't think the style guide allowing casts to void is a strong endorsement, either.

I think std::ignore is probably the consensus for Chromium.

Nico Weber

unread,
Jan 11, 2022, 4:31:51 PM1/11/22
to K. Moon, Mark Mentovai, Avi Drissman, Dana Jansens, cxx
On my system, <tuple> expands to over 10k lines of code. The header defining ignore_result() has 20 lines. `(void)` Just Works.

std::ignore makes sense to me for the LHS of std::tie(), but for ignoring the result or a nodiscard function it:
- looks a bit weird
- adds quite a bit of overhead for the compiler

This doesn't seem like a great change to me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACwGi-7jzkYNEibiFuTsdfSTY-8n%2BJrxyS71bksz7XxV0q25aw%40mail.gmail.com.

Jeremy Roman

unread,
Jan 11, 2022, 6:08:20 PM1/11/22
to Nico Weber, K. Moon, Mark Mentovai, Avi Drissman, Dana Jansens, cxx
Anecdotally I hadn't previously seen std::ignore outside the context of std::tie. I'm not strongly opposed but (void) is much more familiar to me. My impression is that the internal discussion leans away from using std::ignore but is by no means decisive.

Peter Kasting

unread,
Jan 11, 2022, 6:46:17 PM1/11/22
to dan...@chromium.org, Avi Drissman, K. Moon, cxx
I strongly dislike (void), and would prefer anything over it.  :)

It is cryptic and I don't believe it looks any less weird in an objective sense than "std::ignore", which has the benefit of saying exactly what it does.

I vote for std::ignore first and "do nothing" second.

PK

Roland McGrath

unread,
Jan 11, 2022, 7:59:02 PM1/11/22
to Peter Kasting, Dana Jansens, Avi Drissman, K. Moon, cxx
The biggest advantage of `std::ignore` per se is that it's standard and so in theory standard C++ things are more familiar to the average or future C++ coder.  IMHO if `std::ignore` had a no-op `operator()` as well as `operator=`, then standard familiarity would be enough reason to choose it over other alternatives.  The `std::ignore = ...;` usage is certainly well-specified and is the only quasi-obvious thing the standard offers for that (if cast to void is considered "not obvious", since it's far from innately obvious and only seems so to those with long C experience).  https://en.cppreference.com/w/cpp/utility/tuple/ignore does say, "It can also be used to avoid warnings from unused return values of [[nodiscard]] functions."  But I don't know if it's widely known for that purpose and not just the `std::tie` purpose.

Nico has pointed out some practical downsides to `std::ignore` being in <tuple> wrt compilation speed, as well as the general oddity of that, which others have noted.

So I suspect that the solution that has the most consensus is `ignore_result` as it is, though myself I would take `std::ignore = ...` just to get rid of more local idioms and local support for them.

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

K. Moon

unread,
Jan 12, 2022, 11:00:27 AM1/12/22
to Roland McGrath, Peter Kasting, Dana Jansens, Avi Drissman, cxx
The only point I would take issue with above is that base::ignore_result() is well-known, even within Chromium.

Instances of [^(](void)\w: 249 (estimated)

Instances of "ignore_result(": 29 (estimated)

Just for kicks, "std::ignore =": 286 (estimated)

On grep-ability: There are other uses of the string (void), which I tried to exclude as much as possible, but there are still a lot of "suppress unused" uses.

Anecdotally, I've often heard individuals express surprise on hearing about ignore_result() for the first time; ignoring results isn't something one commonly wants to do (good), and when you do hit that compiler diagnostic, you're not going to be pointed at it by the documentation for the diagnostic. Discoverability is very low, and I don't see that changing, absent patching Clang.

Usually when arguments with no clear "best" option like this come up internally, we turn to Code Search to get some data on what developers are actually doing already. The most popular option seems to be std::ignore or (void) by 10x.

The potential compile cost of <tuple> is something to weigh carefully, but the incremental cost may not be that high with a realistic set of other includes. I suspect you're also unlikely to use std::ignore in a header, so hopefully that cost doesn't propagate beyond single .cc files. I guess if we're really worried about it, we could define some sort of base::ignore, so at least it would just be the same idiom spelled differently.

David Benjamin

unread,
Jan 12, 2022, 11:05:41 AM1/12/22
to K. Moon, Roland McGrath, Peter Kasting, Dana Jansens, Avi Drissman, cxx
On Wed, Jan 12, 2022 at 11:00 AM K. Moon <km...@chromium.org> wrote:
This may not be a meaningful comparison as a lot of ignore_results have already been rewritten to std::ignore:

(I have no particular opinions on which of the three to prefer.)
 
On grep-ability: There are other uses of the string (void), which I tried to exclude as much as possible, but there are still a lot of "suppress unused" uses.

Anecdotally, I've often heard individuals express surprise on hearing about ignore_result() for the first time; ignoring results isn't something one commonly wants to do (good), and when you do hit that compiler diagnostic, you're not going to be pointed at it by the documentation for the diagnostic. Discoverability is very low, and I don't see that changing, absent patching Clang.

Usually when arguments with no clear "best" option like this come up internally, we turn to Code Search to get some data on what developers are actually doing already. The most popular option seems to be std::ignore or (void) by 10x.

The potential compile cost of <tuple> is something to weigh carefully, but the incremental cost may not be that high with a realistic set of other includes. I suspect you're also unlikely to use std::ignore in a header, so hopefully that cost doesn't propagate beyond single .cc files. I guess if we're really worried about it, we could define some sort of base::ignore, so at least it would just be the same idiom spelled differently.

On Tue, Jan 11, 2022 at 4:59 PM Roland McGrath <mcgr...@chromium.org> wrote:
The biggest advantage of `std::ignore` per se is that it's standard and so in theory standard C++ things are more familiar to the average or future C++ coder.  IMHO if `std::ignore` had a no-op `operator()` as well as `operator=`, then standard familiarity would be enough reason to choose it over other alternatives.  The `std::ignore = ...;` usage is certainly well-specified and is the only quasi-obvious thing the standard offers for that (if cast to void is considered "not obvious", since it's far from innately obvious and only seems so to those with long C experience).  https://en.cppreference.com/w/cpp/utility/tuple/ignore does say, "It can also be used to avoid warnings from unused return values of [[nodiscard]] functions."  But I don't know if it's widely known for that purpose and not just the `std::tie` purpose.

Nico has pointed out some practical downsides to `std::ignore` being in <tuple> wrt compilation speed, as well as the general oddity of that, which others have noted.

So I suspect that the solution that has the most consensus is `ignore_result` as it is, though myself I would take `std::ignore = ...` just to get rid of more local idioms and local support for them.

On Tue, Jan 11, 2022 at 3:46 PM 'Peter Kasting' via cxx <c...@chromium.org> wrote:
I strongly dislike (void), and would prefer anything over it.  :)

It is cryptic and I don't believe it looks any less weird in an objective sense than "std::ignore", which has the benefit of saying exactly what it does.

I vote for std::ignore first and "do nothing" second.

PK

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

--
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.

K. Moon

unread,
Jan 12, 2022, 11:11:49 AM1/12/22
to David Benjamin, Roland McGrath, Peter Kasting, Dana Jansens, Avi Drissman, cxx
On Wed, Jan 12, 2022 at 8:05 AM David Benjamin <davi...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 11:00 AM K. Moon <km...@chromium.org> wrote:

This may not be a meaningful comparison as a lot of ignore_results have already been rewritten to std::ignore:

I appreciate the caveat, as the results did seem a bit strange to me. Although even then, ignore_result() would be closer to parity than clearly far ahead.

An unrelated point: The documentation for nodiscard explicitly mentions cast-to-void:

I think this is mainly because cast-to-void is a special case in the language, rather than endorsing that solution, but someone might get that impression.

David Benjamin

unread,
Jan 12, 2022, 11:51:09 AM1/12/22
to K. Moon, Roland McGrath, Peter Kasting, Dana Jansens, Avi Drissman, cxx
On Wed, Jan 12, 2022 at 11:11 AM K. Moon <km...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 8:05 AM David Benjamin <davi...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 11:00 AM K. Moon <km...@chromium.org> wrote:

This may not be a meaningful comparison as a lot of ignore_results have already been rewritten to std::ignore:

I appreciate the caveat, as the results did seem a bit strange to me. Although even then, ignore_result() would be closer to parity than clearly far ahead.

I think it's just that the rewrite was mostly done. :-) My checkout happens to be before the first of those comments and...

$ git grep 'std::ignore = ' 073b3397af4ac6ae1f48cd5a90b492071e8d0525 | wc -l
18
$ git grep 'ignore_result(' 073b3397af4ac6ae1f48cd5a90b492071e8d0525 | wc -l
636

(The sums don't match up because code search numbers by file and this counts by line.)

David Benjamin

unread,
Jan 12, 2022, 11:52:01 AM1/12/22
to K. Moon, Roland McGrath, Peter Kasting, Dana Jansens, Avi Drissman, cxx
On Wed, Jan 12, 2022 at 11:50 AM David Benjamin <davi...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 11:11 AM K. Moon <km...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 8:05 AM David Benjamin <davi...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 11:00 AM K. Moon <km...@chromium.org> wrote:

This may not be a meaningful comparison as a lot of ignore_results have already been rewritten to std::ignore:

I appreciate the caveat, as the results did seem a bit strange to me. Although even then, ignore_result() would be closer to parity than clearly far ahead.

I think it's just that the rewrite was mostly done. :-) My checkout happens to be before the first of those comments and...

$ git grep 'std::ignore = ' 073b3397af4ac6ae1f48cd5a90b492071e8d0525 | wc -l
18
$ git grep 'ignore_result(' 073b3397af4ac6ae1f48cd5a90b492071e8d0525 | wc -l
636

(The sums don't match up because code search numbers by file and this counts by line.)

Oh, sorry you meant closer to parity with (void). I misunderstood. Ignore me. :-)

Mark Mentovai

unread,
Jan 12, 2022, 11:53:22 AM1/12/22
to K. Moon, David Benjamin, Roland McGrath, Peter Kasting, Dana Jansens, Avi Drissman, cxx
K. Moon wrote:
On Wed, Jan 12, 2022 at 8:05 AM David Benjamin <davi...@chromium.org> wrote:
On Wed, Jan 12, 2022 at 11:00 AM K. Moon <km...@chromium.org> wrote:

This may not be a meaningful comparison as a lot of ignore_results have already been rewritten to std::ignore:

I appreciate the caveat, as the results did seem a bit strange to me. Although even then, ignore_result() would be closer to parity than clearly far ahead.

Not really. Your query for (void) is picking up a lot of things in a third_party directory that isn’t at the root, buildtools/third_party, in which libc++ resides. It also picks up v8, which is its own repository that’s not dependent on our base, although not in a third_party location. And it picks up a bunch of Objective-C syntax, where the type of a selector for a method without a return type is written as (void), so you need to exclude anything that has apple, mac, ios, or cocoa in the path. (Objective-C/Objective-C++ headers are named with .h, so codesearch’s lang:c++ doesn’t understand that it’s not looking at C++.) So now you’re down from 249 (estimated) to 59 (not estimated). And a little spot-check of those shows that the first isn’t dealing with [[nodiscard]] and is perhaps more of a [[maybe_unused]] than an ignore_result/std::ignore, the next two are oddball uses in macros and aren’t really in scope for the discussion, the fourth and fifth aren’t [[nodiscard]] either, etc. It actually looks like most of these should be [[maybe_unused]]. And this is all actually kind of highlighting another problem with (void), which is that, as I mentioned, it’s a silly overload in the C tradition that can be used for multiple distinct purposes, and I feel that it’s far preferable to use a construct with both documentary value and precise applicability.

(And I say this as a programmer with a long history of working with C. I recognize and understand (void), but the language—particularly C++—has moved on from this.)

The reality is that (void) is exceptionally rare in Chromium code. When it does appear, there are several meanings that it conveys, and the predominant use isn’t even to be an ignore_result/ignore-equivalent. We’ve been on ignore_result for quite a long time (seemingly supporting the proposition that it’s been well-known within Chromium), and most of those have now moved to std::ignore.

Avi Drissman

unread,
Jan 12, 2022, 11:57:17 AM1/12/22
to Mark Mentovai, K. Moon, David Benjamin, Roland McGrath, Peter Kasting, Dana Jansens, cxx
FYI, I was mostly through the migration when the question of "wait, shouldn't we use (void)" arose, and I raised it here. I'm happy to switch my migration depending on the conclusion, but if you want to draw data from the chromium source code, please be sure to do it from a commit before last Thursday or so.

K. Moon

unread,
Jan 12, 2022, 12:46:28 PM1/12/22
to Avi Drissman, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, Dana Jansens, cxx
I ran some queries using git grep -E at 2d70c8faf9d179a6219d0962df522daf32650794 (e0582ecaa5465f52bb8ece183987a5820dd19523^), removing third_party folders that weren't third_party/blink, and removing uses that were in comments.

\(void\)[[:graph:]]*\w\(: 51 lines (after manually removing some instances that were not function calls)
std::ignore =: 18 lines
ignore_result\(: 618 lines

So base::ignore_result() was indeed the most popular by far in chromium/src before crbug.com/1285085; (void) was slightly more popular than std::ignore =, but the numbers are pretty small regardless.

dan...@chromium.org

unread,
Jan 12, 2022, 12:55:02 PM1/12/22
to K. Moon, Avi Drissman, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
On Wed, Jan 12, 2022 at 12:46 PM K. Moon <km...@chromium.org> wrote:
I ran some queries using git grep -E at 2d70c8faf9d179a6219d0962df522daf32650794 (e0582ecaa5465f52bb8ece183987a5820dd19523^), removing third_party folders that weren't third_party/blink, and removing uses that were in comments.

\(void\)[[:graph:]]*\w\(: 51 lines (after manually removing some instances that were not function calls)
std::ignore =: 18 lines
ignore_result\(: 618 lines

So base::ignore_result() was indeed the most popular by far in chromium/src before crbug.com/1285085; (void) was slightly more popular than std::ignore =, but the numbers are pretty small regardless.

I think this shows (void) is not well used, so if std::ignore always existed, it supports we would have chosen it all along over (void). That makes sense given that std::ignore is more precise in its intent and it is "the c++ way".

I suggest we use it unless proven to be too costly for us (compiler-wise). As said earlier, it won't appear in headers often. I think our overall intent is to use standard things over rolling our own unless it's A Problem for some reason.

Daniel Cheng

unread,
Jan 12, 2022, 3:09:40 PM1/12/22
to dan...@chromium.org, K. Moon, Avi Drissman, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
The problem here is the header issue is something that's really only a problem at scale over time.

I would prefer that we just stick with ignore_result() if people really dislike (void) that much.

(I suspect people didn't use (void) just because we had ignore_result)

Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaRptWktk%3DTosnSTpSKM_Li_kn0VCZ0uxpptW0V-4C3_Fw%40mail.gmail.com.

Avi Drissman

unread,
Jan 13, 2022, 2:02:28 PM1/13/22
to Daniel Cheng, Dana Jansens, K. Moon, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
I must admit to confusion in regards to advocacy for ignore_result. I thought that we preferred using standard C++ idioms in preference to one-off custom utility functions. std::ignore is a standard C++ idiom, as is (void). While I prefer the former, I would much rather have the latter than ignore_result.


K. Moon

unread,
Jan 13, 2022, 2:54:55 PM1/13/22
to Avi Drissman, Daniel Cheng, Dana Jansens, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
As a whole, I think there's majority agreement that "std::ignore =" reads the best (more obvious than (void), less idiosyncratic than base::ignore_result()), ignoring the compile cost. The question then is how much to weigh the compile cost (which hasn't been quantified precisely) vs. readability, which could force a decision between base::ignore_result() and (void) instead. (Or doing our own base::ignore, I guess, but I haven't heard much support expressed for that option at this point.)

Between base::ignore_result() and (void), I suspect base::ignore_result() would win, as there isn't much appetite to convert to something less readable (but less idiosyncratic).

Given that the mass conversion to std::ignore is mostly done anyway, I'd suggest staying the course until there's quantitative data saying it's a bad idea (which the conversion might help collect).

K. Moon

unread,
Jan 13, 2022, 3:36:23 PM1/13/22
to Avi Drissman, Daniel Cheng, Dana Jansens, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
For a back-of-the-envelope sense of the impact, I wrote a small microbenchmark that did clang++ -std=c++17 -O2 -c -o /dev/null, and then ran it about 100 times on my Sandy Bridge-era workstation.

The first version of the source I compiled looked like this:
#include <tuple> 

int DoSomething(); 

int main() {
  std::ignore = DoSomething();
  return 0;
}

For this first version, std::ignore took about 5.4 seconds of wall clock time to compile, while ignore_result() and (void) took about 1.4 seconds. Not looking so good for std::ignore, right?

The second version looked like this:
#include <string>
#include <tuple> 
 
int DoSomething(std::string& result); 
 
int main() {
  std::string result;
  std::ignore = DoSomething(result);
  return result.size();
}

For this second version, std::ignore took about 13.2 seconds, while ignore_result() and (void) took about 12.2. Throwing in another header like <vector> increased compile times across the board by about another second for 100 iterations.

For these trivial programs, which should be close to the worst case, the incremental cost of std::ignore is about 10 milliseconds per compilation. I think for non-trivial programs, we shouldn't obsess about the cost of including <tuple>.

Avi Drissman

unread,
Jan 14, 2022, 2:40:19 PM1/14/22
to K. Moon, Daniel Cheng, Dana Jansens, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
First, my sincere apologies to anyone who felt surprised by this. I proceeded to CLs because I thought this wasn't controversial. Once it became clear that it was, I stopped and brought it there, but it's on me that I proceeded at a speed that turns out to have been too fast.

We have at least the question of how to nullify [[nodiscard]]: std::ignore(), (void), or our custom base::ignore_result(). But there also seems to be the meta-question of: do we prefer standard C++ library approaches to custom ones even if those standard approaches aren't quite as clean as our custom ones? I thought the consensus to that latter meta-question was yes, but I'm not sure about that any more.

In a conversation with Dana, she suggested that in a situation like this, a face-to-face or VC meeting to work things out would be a good idea, and I think she's right. The specific folks I want to make sure are included are Nico and Daniel, as I read their emails as them having the strongest objections to the current situation that I started, but I would like to include everyone who wants to have a say.

Is there any objection to this? Have we had cxx tribunals to determine answers to questions before?

Avi

Avi Drissman

unread,
Jan 18, 2022, 7:00:08 PM1/18/22
to K. Moon, Daniel Cheng, Dana Jansens, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
I set up a meeting on Thursday at 4 EST. I invited the Google folks on the thread; if you don't see this on your calendar or if you want to join in and aren't at Google, please let me know and I'll bring you in.

Avi Drissman

unread,
Jan 20, 2022, 4:36:22 PM1/20/22
to K. Moon, Daniel Cheng, Dana Jansens, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
The conclusion is that we're going to finish the migration to std::ignore and remove base/ignore_result.h.

K. Moon

unread,
Jan 20, 2022, 4:37:22 PM1/20/22
to Avi Drissman, Daniel Cheng, Dana Jansens, Mark Mentovai, David Benjamin, Roland McGrath, Peter Kasting, cxx
Thanks for reaching a resolution on this!
Reply all
Reply to author
Forward
0 new messages