5 ms·

I know this is a nitpick, but "auto main() -> int" seems weird to me. "int main()" is not only more understandable, but also shorter.

StephanTLavavej 11y ago
Yep, that's a totally counterproductive use of trailing return types. There are several reasons to use trailing return types, but that's not one of them. (The major use is when you have to refer to function parameters with decltype. Additional uses are when the return type would have to be qualified on the left but can be shorter on the right, or when you're returning something like a function pointer or reference to array and you don't have a convenient typedef/alias.)
- detrino 11y ago
  One could argue that trailing return types are more consistent and allow you to switch between return type deduction and explicit return types easier.
  - AdieuToLogic 11y ago
    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.
    - deleted 11y ago
      [deleted]
    - detrino 11y ago
      What a long winded way to say "that syntax is weird" while totally ignoring that my main point was consistency.
  - byuu 11y ago
    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.
    - AdieuToLogic 11y ago
      > 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.
    - detrino 11y ago
      I didn't realize it was scoped this way, that's a nice bonus.
thrownaway2424 11y ago
Couldn't it even just have been "auto main()" and nothing in c++14?
- StephanTLavavej 11y ago
  No, that was forbidden by the resolution of Core Issue 1669, see: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1669 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html...
andrepd 11y ago
And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it.
- nadams 11y ago
  > And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it. This comment is very interesting. His syntax reminds me of Python syntax of: for i in [1,2,3]: Isn't that what the future C++ is trying to achieve? Simplified syntax?
  - detrino 11y ago
    It's worse in every way to: for (int i = 1; i != 10; ++i)
  - srean 11y ago
    > Isn't that what the future C++ is trying to achieve? Simplified syntax? I think your question was rhetorical, in any case the answer is yes. In fact the proposed C++ pythy syntax tries go even further http://pfultz2.github.io/Pythy/ http://pfultz2.github.io/Pythy/ . IIRC its Clang only. Its author hangs out on HN sometimes and would be able to provide more information
  - andrepd 11y ago
    Even in that example, wouldn't it be better to simply write for i in range(1,4):
- sjolsen 11y ago
  Why? Because that's the most concise way in general to iterate over an arbitrary list of enumerated values. There's no "abuse" here, just a particular example that could have been written more concisely.
  - fauigerzigerk 11y ago
    It's not the most concise way to iterate over a sequence of numbers from 1 to 9. Worse than that, it suggests that there may be a number missing somewhere in the middle. You have to scan the entire sequence with your eyes to be sure. for (int i = 1; i <= 9; ++i) is both more concise and requires less thinking to know what's going on.
gahcep 11y ago
Damn, too much confusion was made. I didn't pay enough attention to these things, my bad. Got rid of it.

StephanTLavavej 11y ago

Yep, that's a totally counterproductive use of trailing return types. There are several reasons to use trailing return types, but that's not one of them. (The major use is when you have to refer to function parameters with decltype. Additional uses are when the return type would have to be qualified on the left but can be shorter on the right, or when you're returning something like a function pointer or reference to array and you don't have a convenient typedef/alias.)

detrino 11y ago
One could argue that trailing return types are more consistent and allow you to switch between return type deduction and explicit return types easier.
- AdieuToLogic 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - detrino 11y ago
    What a long winded way to say "that syntax is weird" while totally ignoring that my main point was consistency.
- byuu 11y ago
  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.
  - AdieuToLogic 11y ago
    > 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.
  - detrino 11y ago
    I didn't realize it was scoped this way, that's a nice bonus.

thrownaway2424 11y ago

Couldn't it even just have been "auto main()" and nothing in c++14?

StephanTLavavej 11y ago
No, that was forbidden by the resolution of Core Issue 1669, see: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1669 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html...

andrepd 11y ago

And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it.

nadams 11y ago
> And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it. This comment is very interesting. His syntax reminds me of Python syntax of: for i in [1,2,3]: Isn't that what the future C++ is trying to achieve? Simplified syntax?
- detrino 11y ago
  It's worse in every way to: for (int i = 1; i != 10; ++i)
- srean 11y ago
  > Isn't that what the future C++ is trying to achieve? Simplified syntax? I think your question was rhetorical, in any case the answer is yes. In fact the proposed C++ pythy syntax tries go even further http://pfultz2.github.io/Pythy/ http://pfultz2.github.io/Pythy/ . IIRC its Clang only. Its author hangs out on HN sometimes and would be able to provide more information
- andrepd 11y ago
  Even in that example, wouldn't it be better to simply write for i in range(1,4):
sjolsen 11y ago
Why? Because that's the most concise way in general to iterate over an arbitrary list of enumerated values. There's no "abuse" here, just a particular example that could have been written more concisely.
- fauigerzigerk 11y ago
  It's not the most concise way to iterate over a sequence of numbers from 1 to 9. Worse than that, it suggests that there may be a number missing somewhere in the middle. You have to scan the entire sequence with your eyes to be sure. for (int i = 1; i <= 9; ++i) is both more concise and requires less thinking to know what's going on.

gahcep 11y ago

Damn, too much confusion was made. I didn't pay enough attention to these things, my bad. Got rid of it.