The new C++ way is

std::ignore = function();

telling the user to check their manual

• So I made an API for a DB.
• The client was full on using Qt Framework with Qt Creator, so I also made it in Qt.
• I return QSqlError in my functions and point the user to QSqlError documentation in Qt
  • I even show them that they can press F1 at any time in Qt Creator to get the help page
• Months later, client engineers raise problem with senior management that they don't have a bool return value (I am sitting 10m away in the same room as the client. Senior management is in another state)
• I press F1 on their computer and show the user bool QSqlError::isValid()
  • Note again, that all client devs at this point, have been using Qt, years before I enter.
• User says they don't have a bool result.
  • I open their code and show them how to use isValid() in an if statement.
• User puts a requirement for custom functions returning bool
  • I make more functions for that
• Months later, I get a bug report, stating that the deleteDocument function is deleting the document but returning false.
• I check the code

API::deleteDocument(docId);

if (API::deleteDocument(docId))
{
  // output to UI
}

Yes, they called deleteDocument on the same ID twice.

BTW, I did create a manual with usage examples.

A few months later, a senior engineer on the client side checks their code and tells me to throw exceptions for everything, because half of the time, the user-devs are not checking the QSqlError return values.

[[nodiscard]]

From what I remember, that gives a warning an not an error.
The clients' code already has >400 warnings^[edit: fixed wrong word] on every build. They won't care

Cool, I didn't know that was a thing 👍

Right, so just cast the returned value to void: (void)function();

I'm mixed on this one, because sometimes you'll want to call a function for its side effects without caring about the return value. E. g. container methods returning an iterator that shows you where the side effect took place.

-Wunused-result is good practice in general

Same, I also like giving this the [[nodiscard]] attribute if I want to make sure that it's not ignored.

I have no problem with localizing error messages... I just think an error handler is the absolutelest wrong place to do it. Localize it in the manual. Appendix C page 3, "Spanish / Español". Error routines should print machine-readable information. A couple numbers. Maybe a smiley (or, given the context, frownley).

For fuck's sake people, stop localizing your error messages.

Yeah they are quite good and they do basically fall under "just wrap an integer".

as long as people are logging pertinent information sure. but I've had the misfortune of working with plenty of programs that return just an error code that means 'something went wrong initialising subsystem X' and left it all to the user to figure out what exactly went wrong, with files and where in those files etc. etc.

Use an enum class, it's strongly typed but the compiler just treats it as an integer

At work we literally just went through this yesterday, just with folly::Expected. A new guy joined the team and wanted to propose we update how we handle errors.

One day the use of auto will grow so extensive that modern Python code will have more type annotations than modern C++ code!

From my discussion with C++ folk, auto is just part of the "modern" way of doing c++. Paired with the -> return type. Perhaps including that -> return type negates this problem? It's still strange to me. Feels more like Rust

This is interesting, but drawing conclusions from only two measurements is not reasonable. Especially so when the time-span measured is in the order of a few ms. For example, the two instances of clang might not be running at the same clock frequency, which could easily explain away the observed difference.

Plus, you could easily generate a very large number of functions, to increase the amount of work the compiler has to do. So I did just that (N = 10,000), using the function from the article, and used hyperfine to perform the actual benchmarking.

• With int

  Benchmark 1: clang -o /dev/null test.cpp -c
    Time (mean ± σ):      1.243 s ±  0.018 s    [User: 1.192 s, System: 0.050 s]
    Range (min … max):    1.221 s …  1.284 s    10 runs
  

• With auto

  Benchmark 1: clang -o /dev/null test.cpp -c
    Time (mean ± σ):      1.291 s ±  0.015 s    [User: 1.238 s, System: 0.051 s]
    Range (min … max):    1.274 s …  1.320 s    10 runs
  

So if you have a file with 10'000 simple functions with/without auto, then it increases your compile time by ~4%.

I'd worry more about the readability of auto, than about the compile time cost at that point

Having the return type name is absolutely better documented. But I guess were splitting hairs because its a hard typed language and lexers can find what it is anyway.

I think you're conflating regular auto use with using it as a return type/argument. The latter is syntactic sugar for declaring a template. It isn't any less "documented" than doing a template<class ReturnType>....

Nuter one of the main reasons for headers: documentation.

Why the fuck do people do this to themselves.

Summary If you want fast compile times, be careful with functions using auto as a return type in header files.

Was hoping to see examples on how to implement everything in C++ without member objects (since that's what class provides, and struct is an alias, or viceversa, whatever), but still was not left at all disappointed.

I think that doesn't respectful to stay in this community for myself. Have a nice day! ✌🏼

Oh good I had forgotten that part!