{"id":2280,"date":"2021-01-17T17:29:41","date_gmt":"2021-01-17T11:59:41","guid":{"rendered":"https:\/\/www.rangakrish.com\/?p=2280"},"modified":"2021-01-17T17:29:41","modified_gmt":"2021-01-17T11:59:41","slug":"c20-nodiscard-attribute","status":"publish","type":"post","link":"https:\/\/www.rangakrish.com\/index.php\/2021\/01\/17\/c20-nodiscard-attribute\/","title":{"rendered":"C++20 [[nodiscard]] Attribute"},"content":{"rendered":"

[[nodiscard]]<\/strong><\/em><\/a>\u00a0attribute \u201c<\/strong>encourages\u201d<\/strong><\/em> the compiler to issue a warning when the return value from a function is ignored. It was introduced in C++ 17<\/strong><\/em> and enhanced in C++ 20<\/strong><\/em> to include a string literal that can be used as an explanation of the warning.<\/p>\n

Let us look at different cases one by one.<\/p>\n

Case-1: An enumeration is marked [[nodiscard]]<\/h4>\n

When a function is defined to return this enumeration, the compiler checks to see if the returned value is discarded. If it is, then the compiler is likely to generate a warning.<\/p>\n

Look at the following code:<\/p>\n

\"Case-1:<\/a>
Case-1: Enumeration<\/strong><\/figcaption><\/figure>\n

Here, the enum class \u201cDeviceStatus\u201d<\/strong><\/em> is marked [[nodiscard]]<\/strong><\/em>, and the function \u201cgetDeviceStatus()\u201d<\/strong><\/em> returns one of the elements of this enum. Next, look at the three calls to this function inside \u201cmain\u201d<\/strong><\/em>. In Line 19, the return value from the function is ignored and this is caught by the compiler. In Line 22, the return value is checked and hence it is OK. In Line 27, we explicitly typecast the result to \u201cvoid\u201d,<\/strong><\/em> indicating that we are ignoring the return value deliberately and hence this is also acceptable (of course, why we chose to ignore is a different issue).<\/p>\n

Here is the compiler output:<\/p>\n

\"Compiler<\/a>
Compiler Output<\/strong><\/figcaption><\/figure>\n

Case-2: A struct\/class is marked [[nodiscard]]<\/h4>\n

In this case, instead of an enumeration, we have a class<\/strong><\/em> or struct<\/strong><\/em> that is marked [[nodiscard]]<\/strong><\/em>.<\/p>\n

\"Case-2:<\/a>
Case-2: Struct\/Class<\/strong><\/figcaption><\/figure>\n

In this case, the function \u201cfoo()\u201d<\/strong><\/em> returns \u201cMyType\u201d<\/strong><\/em> instance by \u201cvalue\u201d<\/strong><\/em>, whereas the function \u201cbar()\u201d<\/strong><\/em> returns by \u201creference\u201d<\/strong><\/em>. In Line 49, the returned value is ignored and hence this triggers a warning. Line 52 is fine. Interestingly, in Line 55, even though we are not using the return value, this does not generate any warning since the return is by \u201creference\u201d<\/strong><\/em>. This is as per the standard.<\/p>\n

Here is the compiler output:<\/p>\n

\"Compiler<\/a>
Compiler Output<\/strong><\/figcaption><\/figure>\n

Case-3: Constructor is marked [[nodiscard]]<\/h4>\n

C++20<\/strong><\/em> allows constructors to be tagged as [[nodiscard]]<\/strong><\/em> (without the struct\/class being so).\u00a0<\/span><\/p>\n

\"Case-3:<\/a>
Case-3: Constructor<\/strong><\/figcaption><\/figure>\n

Notice that there is no issue with Line 69, even though we are ignoring the function return value. This is because the struct \u201cSpecialType\u201d<\/strong> <\/em>is not marked [[nodiscard]]<\/strong><\/em>. However, there is a problem in Line 73. Since the constructor is marked [[nodiscard]]<\/strong><\/em>, the compiler sees that the constructed object is bound to a temporary and hence is not \u201cused\u201d<\/strong><\/em>. On the other hand, lines 76, 78 and 80 are OK since the constructor is used to instantiate \u201creal\u201d<\/strong><\/em> named objects. \u00a0<\/span><\/p>\n

\"Compiler<\/a>
Compiler Output<\/strong><\/figcaption><\/figure>\n

Case-4: A function is declared [[nodiscard]]<\/h4>\n

In this case, instead of a data type (enum\/struct\/class), a specific function<\/strong><\/em> is marked [[nodiscard]<\/strong><\/em>]. See the following example.<\/p>\n

\"Case-4:<\/a>
Case-4: Function<\/strong><\/figcaption><\/figure>\n

Here, the \u201ccomputeSum()\u201d<\/strong><\/em> function takes two arguments and returns a result based on the arguments. It is only natural that we are expected to use the returned value. So, this function is declared [[nodiscard]]<\/strong><\/em>. However, in Line 93, the return value is ignored, triggering a warning, as expected. Line 96, because it uses the return value, is OK.<\/p>\n

\"Compiler<\/a>
Compiler Output<\/strong><\/figcaption><\/figure>\n

This completes the different use cases for [[nodiscard]]<\/strong><\/em>.<\/p>\n

General Question: Should functions return a value?<\/h4>\n

Since the [[nodiscard]]<\/strong><\/em> attribute is about using\/ignoring the return value of functions, it makes sense to ask this general question. As most of us know, this is a \u201cdesign\u201d<\/strong><\/em> question and not a mere \u201cimplementation\u201d<\/strong><\/em> issue.<\/p>\n

Functions return a value for one of three reasons:<\/p>\n

a) The caller depends on the return value and is expected to use it. <\/strong><\/em><\/span><\/p>\n

void * malloc()<\/strong><\/em><\/p>\n

int std::rand()<\/strong><\/em><\/p>\n

float std::floor(float arg)<\/strong><\/em><\/p>\n

In all the above cases, we call the function only for its return value. So is it not an error to ignore the return value? Such functions need to be declared [[nodiscard]]<\/strong><\/em>.<\/p>\n

b) The caller “might” use the return value as “auxiliary” information. It is not essential for further computation and hence could be ignored. <\/strong><\/em><\/span><\/p>\n

int std::printf(const char *format, …)<\/strong><\/em><\/p>\n

Here the return value indicates the number of characters written, or if negative, indicates an error. Most of the time, the return value is ignored.\u00a0These functions should not be marked [[nodiscard]]<\/strong><\/em>.<\/span><\/p>\n

c) The return value adheres to a coding convention and is intended to be used liberally, though not always. Consider the design of “fluent” <\/em>APIs.<\/strong><\/span>\u00a0<\/span><\/p>\n

MyObject obj;<\/strong><\/em><\/p>\n

Obj.doThis().doThat(30).doSomethingElse(\u201cHello\u201d);<\/strong><\/em><\/p>\n

The above could also be written this way:<\/p>\n

MyObject obj;<\/strong><\/em><\/p>\n

Obj.doThis();<\/strong><\/em><\/p>\n

Obj.doThat(30);<\/strong><\/em><\/p>\n

Obj.doSomethingElse(\u201cHello\u201d);<\/strong><\/em><\/p>\n

Here, the use of return value promotes a stylistic convention, and is not a rigid rule. Such functions should not be marked [[nodiscard]]<\/strong><\/em> (in my opinion).\u00a0<\/span><\/p>\n

Whether to declare an enum\/class\/struct\/function as [[nodiscard]]<\/strong><\/em> requires careful deliberation, and once decided, C++ allows us to explicitly declare our intention. This is a useful feature and we should start using this in our code.<\/p>\n

That is it for now. Hope you found the above discussion informative. You can download the sample code from here<\/strong><\/em><\/a>.<\/p>\n

Take care and have a nice weekend!<\/p>\n","protected":false},"excerpt":{"rendered":"

[[nodiscard]]\u00a0attribute \u201cencourages\u201d the compiler to issue a warning when the return value from a function is ignored. It was introduced in C++ 17 and enhanced in C++ 20 to include a string literal that can be used as an explanation of the warning. Let us look at different cases one by one. Case-1: An enumeration […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[49,17],"tags":[67,262],"class_list":["post-2280","post","type-post","status-publish","format-standard","hentry","category-c","category-programming","tag-c","tag-nodiscard"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9OLnF-AM","jetpack-related-posts":[{"id":2850,"url":"https:\/\/www.rangakrish.com\/index.php\/2022\/06\/26\/c20-no_unique_address-attribute\/","url_meta":{"origin":2280,"position":0},"title":"C++20 [[no_unique_address]] Attribute","author":"admin","date":"June 26, 2022","format":false,"excerpt":"The [[no_unique_address]] attribute was introduced in C++20 to give a compiler the freedom to optimise memory allocation of a struct\/class when it contains a subobject that does not have any members. The other requirement is that the subobject should not be a static member of the enclosing struct\/class. Let us\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Empty vs. Non-empty Struct","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2022\/06\/code1-300x213.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2022\/06\/code1-300x213.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2022\/06\/code1-300x213.jpg?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":3675,"url":"https:\/\/www.rangakrish.com\/index.php\/2025\/04\/24\/interfaces-without-inheritance-comparing-c-and-common-lisp\/","url_meta":{"origin":2280,"position":1},"title":"Interfaces Without Inheritance: Comparing C++ and Common Lisp","author":"admin","date":"April 24, 2025","format":false,"excerpt":"Clean interface design is a crucial aspect of software engineering since it enables code flexibility, reuse, and maintainability. Developers who prefer an object-oriented approach typically rely on inheritance to define the interface and thus establish type relationships. While this can lead to a good design if approached carefully, detractors of\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Rectangle and Circle Defined","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2025\/04\/cpp2-251x300.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":739,"url":"https:\/\/www.rangakrish.com\/index.php\/2017\/12\/17\/c17-constexpr-if\/","url_meta":{"origin":2280,"position":2},"title":"C++17: constexpr if","author":"admin","date":"December 17, 2017","format":false,"excerpt":"constexpr if is another nice little feature in C++17, which significantly simplifies the way we code, especially in the context of templates. In this article, I will briefly talk about this feature and look at some examples. constexpr if is a variant of the standard if statement we have had\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Example1","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/12\/Example1-1.png?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":198,"url":"https:\/\/www.rangakrish.com\/index.php\/2016\/04\/08\/c14-return-type-deduction-for-normal-functions\/","url_meta":{"origin":2280,"position":3},"title":"C++14: Return Type Deduction for Normal Functions","author":"admin","date":"April 8, 2016","format":false,"excerpt":"In C++11, a function must specify its return type in one of the following two ways: int aFunction(int arg) { \u00a0 \u00a0 return arg * 2; } (or) auto aFunction(int arg) -> int { \u00a0 \u00a0 return arg * 2; } The first is the classic function definition syntax. The\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2540,"url":"https:\/\/www.rangakrish.com\/index.php\/2021\/09\/19\/c-20-concepts\/","url_meta":{"origin":2280,"position":4},"title":"C++ 20: Concepts","author":"admin","date":"September 19, 2021","format":false,"excerpt":"Concepts, introduced in C++20, are predicates that act as contraints on template parameters. As you would expect, the nice thing is that the constraint checking happens as part of template instantiation at compile time and not at run time! Since templates can have type as well as non-type parameters, Concepts\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Constraint on Type","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2021\/09\/Example1-300x213.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":2722,"url":"https:\/\/www.rangakrish.com\/index.php\/2022\/03\/06\/lazy-parameter-evaluation-in-d-language\/","url_meta":{"origin":2280,"position":5},"title":"Lazy Parameter Evaluation in D Language","author":"admin","date":"March 6, 2022","format":false,"excerpt":"Languages such as C\/C++ and Java follow an\u00a0\"eager\" argument evaluation approach, where function arguments are evaluated before the function is entered. Of course, there are idioms and tricks that one can use to force \"lazy\" evaluation. The primary benefit of \"lazy\" parameter evaluation is that the parameter is evaluated only\u2026","rel":"","context":"In "D Language"","block_context":{"text":"D Language","link":"https:\/\/www.rangakrish.com\/index.php\/category\/d-language\/"},"img":{"alt_text":"Example Program","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2022\/03\/eagercode-237x300.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts\/2280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/comments?post=2280"}],"version-history":[{"count":0,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts\/2280\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/media?parent=2280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/categories?post=2280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/tags?post=2280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}