In D14721#407444, @bartek wrote:

Alternative is to move implementation to .cpp file, but not sure if this is worth it, I think the compiler will optimize it anyway, and I don't think this is worse in terms of readability.

I was about to disagree about this one, but sounds like you're right, things have changed in modern C++. From docs, especially the last paragraph:

The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times.

Since inline substitution is unobservable in the standard semantics, compilers are free to use inline substitution for any function that's not marked inline, and are free to generate function calls to any function marked inline. Those optimization choices do not change the rules regarding multiple definitions and shared statics listed above.

Because the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred" since C++98, that meaning was extended to variables.

But I still think we shouldn't overuse this pattern (function definitions inside .h files)

Agree on this