4 ms·

Herb Sutter offers another viewpoint: In particular: #5 on that page: "we see that the right-hand style is not only more robust and maintainable for the reason

Herb Sutter offers another viewpoint: In particular: #5 on that page: "we see that the right-hand style is not only more robust and maintainable for the reasons already given, but also arguably cleaner and more regular with the type consistently on the right when it is mentioned" [1] https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style...

MaxBarraclough 6y ago
I don't think Herb's points apply to an ordinary declare-an-object-and-immediately-initialize-using-the-constructor, do they? He gives an example using aggregate initialization, but that's not the same thing: // Classic C++ declaration order // Modern C++ style employee e{ empid }; auto e = employee{ empid }; widget w{ 12, 34 }; auto w = widget{ 12, 34 }; He makes the case that it's nicer to use auto pretty much wherever we can, to avoid repeating ourselves regarding type, and to avoid unexpected conversions. The auto keyword doesn't apply in our case, there's no way to use auto to simplify a statement like: Widget w(1,2,3);
- Koshkin 6y ago
  Exactly. auto is only useful in contexts where the type is expected to be inferred (by the compiler).
- SloopJon 6y ago
  Actually, he does discuss this in section 4b. He doesn't come out as strongly in favor of it, "The jury is still out on whether to recommend this one wholesale," although he does list what he considers some advantages. He also acknowledges in section 6 that it doesn't work for non-moveable types. Despite my tendencies towards almost-always auto, I can't say that I consistently use auto x = type{init}, but there is certainly nothing wrong with it.
  - gpderetta 6y ago
    > He also acknowledges in section 6 that it doesn't work for non-moveable types. Actually these days it does. Copy/Move elision is mandated by the language in this case and no valid copy/move constructor is required. Similarly is no possible to return non-movable non-copyable types from functions which opens the possibility of interesting code patternes.

MaxBarraclough 6y ago

I don't think Herb's points apply to an ordinary declare-an-object-and-immediately-initialize-using-the-constructor, do they? He gives an example using aggregate initialization, but that's not the same thing: // Classic C++ declaration order // Modern C++ style employee e{ empid }; auto e = employee{ empid }; widget w{ 12, 34 }; auto w = widget{ 12, 34 }; He makes the case that it's nicer to use auto pretty much wherever we can, to avoid repeating ourselves regarding type, and to avoid unexpected conversions. The auto keyword doesn't apply in our case, there's no way to use auto to simplify a statement like: Widget w(1,2,3);

Koshkin 6y ago
Exactly. auto is only useful in contexts where the type is expected to be inferred (by the compiler).
SloopJon 6y ago
Actually, he does discuss this in section 4b. He doesn't come out as strongly in favor of it, "The jury is still out on whether to recommend this one wholesale," although he does list what he considers some advantages. He also acknowledges in section 6 that it doesn't work for non-moveable types. Despite my tendencies towards almost-always auto, I can't say that I consistently use auto x = type{init}, but there is certainly nothing wrong with it.
- gpderetta 6y ago
  > He also acknowledges in section 6 that it doesn't work for non-moveable types. Actually these days it does. Copy/Move elision is mandated by the language in this case and no valid copy/move constructor is required. Similarly is no possible to return non-movable non-copyable types from functions which opens the possibility of interesting code patternes.