[webkit-dev] When to use "auto"? (I usually consider it harmful)

[Darin Adler]

On Jan 4, 2014, at 9:10 AM, Andreas Kling <akling at apple.com> wrote:

> On Jan 4, 2014, at 4:14 PM, Alex Christensen <alex.christensen at flexsim.com> wrote:
> 
>> Call me an extremist, but I would be in favor of a complete ban on auto. I've been involved in another project deciding to not use auto at all. It forces programmers to be explicit and careful, it shows the effects of type changes with compiler errors (exposing bugs better), and it's easy to enforce with no debate.
> 
> I don’t agree that this is a good thing.

Yes, I also do not agree. We should not ban “auto”!

I am happy with the effect “auto” has already had on code I have worked on since we’ve started using it.

> My favorite thing about “auto" is how it automatically takes advantage of
> functions getting narrower return types, e.g when changing something in
> WebKit to return Element instead of Node. If all call sites are using “auto”,
> they may now generate more efficient code (avoiding isElementNode() checks,
> FINAL overloads, etc.) without having to touch the source.

Yes, I really like this too.

I also think it’s fantastic for those complex template type names that contain little useful information, such as iterating types, and to avoid repeating types already mentioned on the same line of code, as pointed out by Antti.

Personally, I have yet to run into a single time when reading or modifying code where I had a problem with lack of clarity because of auto. There are so many other things which you can’t see when reading a line of C++ code, which I think is a good thing — part of what makes C++ a high level language. To create a straw man, imagine what it would be like if we had to say “inline” at each call site of an inline function or “virtual” every time we called a virtual function. I’d like to be able to refine the return type of a function without having to visit every call site, just as I can change a function to be an inline or a virtual without doing so.

If you’d pardon my somewhat condescending speculation, I think we’ve become attached to something, seeing the type name for each type written at the declaration, that on balance is more of an artifact than a helpful programming tool. At its worst, it can actually degrade the type of an expression, as when it needlessly turns an Element* into a Node*, or make otherwise straightforward code needlessly hard to read.

It’s true that some of our types are difficult to use correctly. I can see that in the case of smart pointers it might be critical to see whether something is a RefPtr or a Ref or a raw pointer. Not sure how to reconcile that cost with the benefits I see.

— Darin