But what about something like this?

template<typename T>
auto make_foo(T&& foo_arg) {
    return foo<std::decay_t<T>>{std::forward<T>(foo_arg)};
}

This is exactly the pathological case you gave as example, but I find this extremely readable. Specifying the return type would actually not help at all and the pattern the easily recognizable in the end.

If your naming is bad, arguments not clear, and implementation not recognizable and hard to infer what it’s doing then that’s a totally different problem and I would say trailing return type and deduced return type is the least of my concerns.

I use trailing return type exclusively. It just makes the code more readable. Compactness is almost unaffected and readability is more important anyway. Trailing return type is also more compact in many normal cases non temaplate case so I think that argument is moot.

The name of the function is the first thing you want to read. The most important thing once you found your function is then it’s parameters. If you found the right overload, you know the parameters and what they mean then you want to know what it returns.

Trailing return type just have better ergonomics for the reader and also align the functions as a bonus. It so make name resolution better too.

I saw the article on my mastodon feed. When it’s interesting I usually post it here

There are things you’ll want to do that will eventually require pointers. For example, as soon as you want a type that contains a reference that could be rebound, you need a pointer.

If you want to implement polymorphism you’ll need pointers. If you instead want type erasure, you’ll need pointers to implement your type erasure container.

Sure it’s possible to implement a lot without pointers, but the code will be harder to write and will probably be slower.

I had designed a system with what I thought was a good API, wrote the test for it and I was satisfied how simple it was to use the thing but then, when it came to integrate it, it was clunky and no good way to actually use the system.

I don’t think it’s always obvious when an API is good or bad, even with tests.

IMO this change is more useful than I thought. Anybody knows if it’s implemented in Clang too?