It is useful in very specific cases when using templates since C++ compiler processes from left to right and template types are not in scope before the function signature. Using auto keyword you can work around it specifying auto before the function signature and then later once everything is in scope, you specify the actual type via "->".

TypeScript also has the type after the method/function, I think to make it easier to re-use and port existing JavaScript code.

I prefer to put return types on their own line:

MyReturnType
doTheThing(int arg1, float arg2);

This keeps function names aligned vertically, which I find helps with readability. It also gives long return types an entire line to work with.

While I do like using auto inside function definitions, I don't like it for return types because it hurts readability. Having the explicit type available to the reader reduces cognitive load. I use trailing return types on non-trivial lambda functions for this same reason.

Trailing return types are strictly superior since they allow the type to be written in terms of arguments, if necessary.

Deduction can sometimes take its place but often makes the code less obvious.

A minor side-effect is that it makes all function names line up, without introducing line breaks (which break grep). If only we could do the same for variables ...

I don't use it myself, but I don't have a strong opinion on that. My beef if with deduced return types, especially with templates. It is typical in modern C++ code to see such function:

template<typename ~whatever~>
auto foo(~some arguments which types are deduced from nested templated conditional using declarations that you don't understand~) {
    return ~call to other template function that's 10 levels deep and is also conditional on properties of template parameters with some ifdefs for fun~;
}

That makes it absolutely impossible to figure out what types function takes as parameters and what type it returns until you hit 10-page compiler error that will explain everything (which is also will force you to read through implementation details of this function to figure out how to fix it). And often IDEs can't help you either.

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.

The type annotations in Python are the same: def functionname() -> ReturnType: ...

I have yet to take a liking to auto.