[[nodiscard]]

[lufriem]

I noted the absence of the C++ [[nodiscard]] attribute in the vsg codebase. I think it might be beneficial to have this for functions like

template<typename T> constexpr t_vec3<T> normalize(const t_vec3<T>& v) { return v / length(v); }

With the decoration it would look like this

template<typename T> [[nodiscard]] constexpr t_vec3<T> normalize(const t_vec3<T>& v) { return v / length(v); }

And compilers (MSVS in my example) would complain like this

warning C4834: discarding return value of function with 'nodiscard' attribute

if the caller (yours truly) messed up and ignored the return value (thinking that a non-const reference was passed in).

This attribute was added with C++17 (which vsg is using/requiring anyway), so I wonder if there's any reason against adding this? I need any help I can get with checking my code, so if there's something the compiler/tools can offer, why not take advantage?

[robertosfield]

Readability of compiler hints is not good for casual human parsing of the code. As far as humans are concerned the important bit is vec3 normalize(vec3), everything else hides this amongst a thicket of syntax.

A user making a mistake of not storing/using the return value of normalize(vec3) is something hopefully users will rarely make and when they do basic debugging of non working code should fix it. So for that very rare and benign error do we want to add a burden in reading to all users?

If there is common error which has difficult to detect and has dangerous consequences then adding extra hints that not handling a return type will provide a compelling overhead vs reward ratio, if not the burden may well not justify it.

So a blanket use this C++ feature because it's there is something we need to be very wary of. C++ features need to justify there use, there is so much rope in C++ to hang ourselves with that we need to be ever mindful slipping down a slope into code that is technically correct but largely unusable.

FYI, I've been using C++ for 31 years, seen it grow and blossom in lots of good but also some less helpful directions. I've spent the last 23 years reviewing, merging and fixing open source submissions from thousands of developers, easy human readability has been hallmark of long term reliable and maintainable code.