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

> On Jan 4, 2014, at 4:14 PM, Alex Christensen <alex.christen...@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
webkit-dev mailing list

Reply via email to