Thanks for the kind words 🙂
No we didn’t check std::expected … i’ll give it a look !
too bad std optional doesn’t support references ..
Feel free to share the link with your readers 🙂

Went through the document and it’s excellent. I’d advise all the readers to have a look at your presentation on good APIs.
A couple of feedback notes:
– jtl::result is a great idea. It made me think about std::expected planned for C++20 (and Boost Outcome). Did you have a look at that?
– you may not be able to use std::optional in C++17 because std::optional does not support references (unlike boost optional)
Thanks for sharing this Mihai.

Hi Mihai, I’ll have a look at this document, and will provide my feedback on it.

https://codepatcher.wordpress.com/2017/07/04/a-tale-of-evolving-apis/

Any feedback is appreciated !

I guess I’m reconsidering strong types from a different perspective: API implementers. They are great for encouraging strict type adherence in any case. They are great in providing the facilities for the user to write expressive and optimal code… but in the case of return types, it depends entirely on API user not being lazy.

When the api user is lazy, they will use auto variables or even use the return types directly, in which case neither a typedef nor named types offers any real advantage. It seems to me that the only way to provide the real advantages that named types offer for return values is to require the user to access it via a named member – either variable or function.

And it’s kinda going too far to call such a user lazy even. From what little I’ve heard, auto is increasingly recommended as C++ is modernized, and direct “inline” usage of return types might the right thing to do for some scoping situations.

Thanks for your comment Bryce. Just making sure that I understand well: what is the advantage of having the named type if they can hide it behind auto? Is it because the last of your code snippet would prevent block compilation, since the named type is not convertible to a bool?

Sure, I guess “named-member”-based interface would be a good generalization of a naming principle that is less “erasable”.

> a method-based result interface
In this case, a simple POD struct would fit the need no?

bool result = save(myData); // or auto result...

or if they’re trying to be extra efficient on typing (there lots of them out there):

if( !save(myData) ) {
  // now what?
}

The advantage of the named type is that it exerts a stronger forcing function of the API’s user to get it right. Even if they do name their result poorly, they will still have the type info:

auto result = save(myData);
if( !result ) {
  ...
}