<div dir="ltr">Adding a few other people who also agreed that nodiscard on StringRef was overly aggressive.<div><br></div><div>StringRef is not a class which -- by design -- must be checked lest the programmer has written erroneous code.  As a result, LLVM_NODISCARD is fundamentally not the right tool.  For the same reason we wouldn't want LLVM_NODISCARD on std::string or const char *.  It is far too versatile a class.  LLVM_NODISCARD means, literally "If you dont' check this return value, your code has a bug".  <br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 27, 2016 at 6:24 PM Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> writes:<br class="gmail_msg">
> After some discussion on IRC, I removed this from StringRef.  It doesn't<br class="gmail_msg">
> seem appropriate for every function that ever returns a StringRef to<br class="gmail_msg">
> require having its return value checked.  One could easily imagine a<br class="gmail_msg">
> function like this:<br class="gmail_msg">
><br class="gmail_msg">
> StringRef insert(StringRef S) {<br class="gmail_msg">
>   // compute a hash of S, store it in some hash table, then return the hash<br class="gmail_msg">
> as a StringRef.<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> where someone doesn't care about the actual hash code, they just want to<br class="gmail_msg">
> insert it.  This is a contrived example, but in any case, this is not much<br class="gmail_msg">
> different than const char *.  Just because a function returns a const char*<br class="gmail_msg">
> doesn't mean I care about the return value.<br class="gmail_msg">
<br class="gmail_msg">
But if people don't care about the hash code, why does insert() even<br class="gmail_msg">
return it? Similarly, what functions return a `const char *` where you<br class="gmail_msg">
don't care about the return value? I feel like the vast majority of<br class="gmail_msg">
functions that return either a `StringRef` or a `const char *` expect<br class="gmail_msg">
you to use the return value, and if you're ignoring it you probably<br class="gmail_msg">
either called the wrong function or are doing something weird (like<br class="gmail_msg">
calling an accessor function for side effects) and having to add a void<br class="gmail_msg">
cast will make that clearer.<br class="gmail_msg"></blockquote><div><br></div><div>The designer of a library cannot guarantee what a user of a library is interested in.  A common paradigm is for a map to have a function like TryInsert that returns a bool if the insert succeeded.  Does the user care whether the insert succeeded?  Sometimes.  </div><div><br></div><div>You may be right about "the vast majority of functions that return a StringRef".  (I'm not saying you are, btw, just that I don't have any data for or against, so maybe you are, and maybe not).  But certainly not all functions, for the same reason that you might not check any other return value.  What makes StringRef different than bool, int, Foo, or std::string in this regard?</div><div><br></div><div>llvm::Error is a good example of a class where LLVM_NODISCARD makes sense at the class.  StringRef, however, I strongly disagree with.</div></div></div></div>