C++11 Feature Proposal: auto

[Peter Kasting]

What: Allow limited use of "auto" in place of an explicit type

Why: Can improve readability in cases of local variables with long, boilerplate typenames, especially common when using STL containers or loop iterators

Why not: Egregious use of "auto" can harm readability

Detail: I propose we allow "auto" under the same rules as the Google style guide: only for local variables, and when its use allows you to avoid type names that are "just clutter" and when an explicit typename would not "help readability".

Those quotes are from https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#auto .  I don't think we actually need to say anything more in the Chromium style guide; these rules admittedly involve judgment calls, but I think they're pretty clear, and usually the right answer should be apparent.  The style guide gives several illustrative examples, pro and con.  The intent is basically "be judicious".  If there's serious question about the use of auto in some case, it's probably better not to use it.

PK

[Alex Vakulenko]

I would suggest one bit of rule relaxing vs google3, related to using "auto" with trailing function return types, when using in template context.

I personally wouldn't care for (if not be outright against) using trailing return type syntax with regular functions like:

int foo();  // good

auto foo() -> int; // why would you do this?

But when working with templates, sometimes you can't do anything without this being allowed:

template<typename U, typename V>

auto multiply(U u, V v) -> decltype(u*v);

Sure, this example relies on another feature, decltype in this case, but this is not strictly required.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Peter Kasting]

On Wed, Sep 24, 2014 at 4:26 PM, Alex Vakulenko <avaku...@chromium.org> wrote:

I would suggest one bit of rule relaxing vs google3, related to using "auto" with trailing function return types, when using in template context.

I personally wouldn't care for (if not be outright against) using trailing return type syntax with regular functions like:

int foo();  // good

auto foo() -> int; // why would you do this?

But when working with templates, sometimes you can't do anything without this being allowed:

template<typename U, typename V>

auto multiply(U u, V v) -> decltype(u*v);

Sure, this example relies on another feature, decltype in this case, but this is not strictly required.

I think that's a reasonable argument but should be discussed under a proposal about how to handle trailing return types instead of here.  (I don't see trailing return types on the list of TBD features, it probably should be.)

PK 

[James Robinson]

On Wed, Sep 24, 2014 at 4:32 PM, 'Peter Kasting' via Chromium-dev <chromi...@chromium.org> wrote:

I think that's a reasonable argument but should be discussed under a proposal about how to handle trailing return types instead of here.  (I don't see trailing return types on the list of TBD features, it probably should be.)

Trailing return types are explicitly banned by the Google C++ style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#C++11, so I don't see a reason to discuss them.

- James

 

[Aaron Boodman]

+1

--

[Peter Kasting]

I think Alex' entire email consists of an argument to discuss them: the ability to do certain kinds of template declarations otherwise not possible.  If he thinks this is actually useful in Chromium, it seems plausible he could start a thread requesting an exemption from the Google style guide.  (I'm not sure I would actually be in favor of doing so.)  I'm mostly trying to prevent it from being discussed here, since I think the proposal is about trailing return types and not about auto per se.

PK

[Nico Weber]

+1

[Alex Vakulenko]

The reason why I brought up trailing return type syntax because the subject of this thread is "auto". And not "auto for type inference". In C++11 keyword "auto" has two distinct meanings that are almost unrelated (thank goodness for dropping the third, legacy meaning of auto for "automatic storage duration").

[Peter Kasting]

On Wed, Sep 24, 2014 at 5:21 PM, Alex Vakulenko <avaku...@chromium.org> wrote:

The reason why I brought up trailing return type syntax because the subject of this thread is "auto". And not "auto for type inference".

My intent with "What: Allow limited use of "auto" in place of an explicit type" and the subsequent description was to make clear I was proposing to allow auto for type inference.  Sorry if the vague subject line was misleading :(.  As I suggested before, I think if you're a big enough fan of (any form of) trailing return type (and using auto in the process) to want us to allow it in Chromium, then since as you mention that's a fairly distinct meaning, it probably makes sense to be on a dedicated thread.

PK

[James Robinson]

+1 from me as well.  It might be useful to point to that section of the style guide and specify that in disagreements folks should escalate to the styleguide/c++/OWNERS, at least for a little while, since I'm sure folks will disagree on what is clutter and what isn't as they get used to the feature.

- James

 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Alex Vakulenko]

That makes sense.

P.S. I'm not a big fan of trailing type syntax. In fact I hope I was clear in saying that it should be disallowed for cases where you can do without it. It just in some (rare) cases there is no solution, but use the trailing type syntax (that's why it was introduced in C++11 standard in the first place).

[Maciej Pawlowski]

W dniu 2014-09-25 01:14, 'Peter Kasting' via Chromium-dev pisze:

What: Allow limited use of "auto" in place of an explicit type

Why: Can improve readability in cases of local variables with long, boilerplate typenames, especially common when using STL containers or loop iterators

Why not: Egregious use of "auto" can harm readability

+1
There are more reasons to use "auto" than just convenience. Herb Sutter had a nice talk on this during Cppcon 2014, the other arguments were:
- Guarantees no implicit conversion and narrowing.
- Potentialy less maintenance, ex. if you change a container type, you don't have rippling changes for all X::iterator declarations in code, "auto i = container.begin();" still works. When you change a container argument to const, you don't have to change X::iterator to X::const_iterator etc.
- Makes you focus on programming against interface rather than implementation, so more generic (in principle).

"auto" can be overused, as any feature, and lead to "OCamling" the language:
auto f = foo();  // What can I do with 'f'? Let's jump to the declaration of foo() and see.
auto foo() { return goo(); }  // A-ha! C++14 automatic return type inference. Go deeper?
auto goo() { return loo() + poo(); }  // What are the types returned by loo() and poo()? Do they have an operator+ defined? What type does this operator return?
At this point, either you have an IDE/editor that understands autos (clang-based?) or you're screwed.

So +1 for using auto for locals with long types, loop iterators or other places where the reader can still understand what's going on without jumping through headers too much.

PK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

-- 
BR
Maciej Pawlowski
Opera Desktop Wroclaw

[Antoine Labour]

On Thu, Sep 25, 2014 at 1:00 AM, Maciej Pawlowski <mpawl...@opera.com> wrote:

W dniu 2014-09-25 01:14, 'Peter Kasting' via Chromium-dev pisze:

What: Allow limited use of "auto" in place of an explicit type

Why: Can improve readability in cases of local variables with long, boilerplate typenames, especially common when using STL containers or loop iterators

Why not: Egregious use of "auto" can harm readability

+1
There are more reasons to use "auto" than just convenience. Herb Sutter had a nice talk on this during Cppcon 2014, the other arguments were:
- Guarantees no implicit conversion and narrowing.
- Potentialy less maintenance, ex. if you change a container type, you don't have rippling changes for all X::iterator declarations in code, "auto i = container.begin();" still works. When you change a container argument to const, you don't have to change X::iterator to X::const_iterator etc.

One of the readability principles is that we optimize for the reader, not for the writer.

 

- Makes you focus on programming against interface rather than implementation, so more generic (in principle).

I'll argue that this is the dangerous part. It's not a strongly typed interface, it's a duck-typed one. At scale it causes the same maintainability problems as weakly typed languages, and we don't have tools to debug type inference.

Antoine

[Peter Kasting]

On Thu, Sep 25, 2014 at 11:25 AM, 'Antoine Labour' via Chromium-dev <chromi...@chromium.org> wrote:

It's not a strongly typed interface, it's a duck-typed one. At scale it causes the same maintainability problems as weakly typed languages, and we don't have tools to debug type inference.

I think your concern is legitimate, and I think it's part of the reason the Google style guide limits the use of auto to the sort of "local scope, type is obvious" cases it does.  I don't think there's a big weak-typing problem when you're replacing a container iterator's type declaration with auto.  I do think there's a problem when you use auto at larger scope.

PK

[Nico Weber]

This is now in the "allowed" list: http://chromium-cpp.appspot.com/

Please follow the Google Style Guide on auto (linked to from the auto entry on chromium-cpp).

On Wed, Sep 24, 2014 at 4:14 PM, 'Peter Kasting' via Chromium-dev <chromi...@chromium.org> wrote:

--

[Antoine Labour]

Agreed. OK when used locally when it helps readability. Not OK when used at larger scopes.

Antoine

 

PK