One could argue that trailing return types are more consistent and allow you to switch between return type deduction and explicit return types easier.

In addition, it's also more consistent with lambda syntax, lets you use decltype on parameter arguments, allows your function names to line up nicely in header files, and my favorite feature, is scoped for member functions. Ex:

    MessageWindow::Response MessageWindow::question(...);
    MessageWindow::Icon MessageWindow::getIcon() { return _icon; }
    ...
    auto MessageWindow::question(...) -> Response;
    auto MessageWindow::getIcon() { return _icon; }

I was fairly nervous about it at first, but after using this syntax, I've grown to highly favor it. Being a huge fan of consistency, I've begun using only this style. Downside is it seems to annoy many other programmers much moreso than other style choices (like const foo vs foo const, tabs vs spaces, K&R vs 1TBS, etc.)

I do kind of wish you could say "function" instead of "auto" here, but of course that wasn't a reserved keyword so it would have broken existing code.

For the ubiquitous main, "auto main() {}" return type deduction works pretty well. But I need a wrapper around main() anyway thanks to Windows corrupting argv[] when you pass in non-ANSI (Unicode) characters. So for my case, I have:

    #include <nall/main.hpp>
    auto nall::main(vector<string> args) { ... }

Where internally, the real main() will use CommandLineToArgvW + WideCharToMultiByte on Windows to return UTF-8 arguments. So many cross-platform apps skip this step, and make opening files named in other languages impossible via command-line.

> In addition, it's also more consistent with lambda syntax, lets you use decltype on parameter arguments, allows your function names to line up nicely in header files...

Great points for the repurposing of auto present in the latest standard... Not for use in defining main.

Your case regarding Windows and wrapping main I'm sure is valid. But is not the case with the article's definition.

I didn't realize it was scoped this way, that's a nice bonus.

One could present that argument, yes, but would be questioned as to why the argument is needed for the canonical main function definition.

Usage of this syntax for main not only deviates from expected form, its presence in defining the one function every C++ developer knows by heart is self-defeating.

What a long winded way to say "that syntax is weird" while totally ignoring that my main point was consistency.