[webkit-dev] [webkit-reviewers] usage of auto

[Simon Fraser]

> On Jan 10, 2017, at 9:03 PM, Darin Adler <darin at apple.com> wrote:
> 
> This kind of discussion should be on webkit-dev, not webkit-reviewers. While the reviewers may have more standing to decide about such things, we normally want to discuss them in the open.

Agreed. Moving there.

> If you don’t like “auto”, please first ask yourself first whether it is because of years of experience reading and writing C++ code without it.
> 
> I like auto, auto&, and auto* pretty much everywhere they can be used. (I almost never like const auto& or const auto*.)
> 
> As Brady pointed out, I find that auto* helps make it clear something is a pointer, and I often prefer that to auto when a pointer is involved.
> 
> Without auto, we often convert types unnecessarily, for example, we call a function and put a pointer to a RenderElement into a RenderObject*. Or convert integer types from one integer type to another unnecessarily. Or convert a Ref to a RefPtr even though the function we are calling can never return a null.
> 
> It’s easy to get the illusion that if you don’t use auto you can “see” the types in the program, but this true only in a limited sense. You can’t see the types of expressions and subexpressions, only of variables. And if you use auto, you can see that there is no type conversion. But if you use an explicit type, you can’t see whether the type on the left matches the type on the right, so this actually hides the “no type conversion here” information.
> 
> It’s often irrelevant what the type is to understanding the code, more important to know what a value represents rather than its type. Specific types can be a distraction. For example, if I am iterating a collection and adding together the result of calling the width function on each element, do I need to state what kind of object is in the collection? It both seems unimportant, and can be a distraction. Arguably, the type of the result of the width function is important, but I don’t know a way to make *that* type visible. I can make what type I put the result into visible, but that still doesn’t tell me what the type of the return value of the width function is.
> 
> I agree with Filip it can be good to write out the name of the type when we want to document what the type is. But for me, this almost never comes up in the kind of programming that I do on the project.
> 
> I’d love to see examples where using auto substantially hurts readability so we could debate them.

Some contrary examples in code that I’ve seen/reviewed:

auto countOfThing = getNumberOfThings();
ASSERT(countOfThing >= 0);  // Can’t tell by reading whether the ASSERT is assured at compile time if countOfThing is unsigned

auto thingLength = getLengthOfThing();
IntSize size(thingLength, 2); // Can’t tell by reading if thingLength is LayoutUnit or float and thus truncated here.

Another common issue in code I’m not familiar with is something like:

auto fancyStyleThing = styleMagic.styleThingForDoohicky()

where it maybe obvious to the author what the type of fancyStyleThing is, but without looking at StyleMagic::styleThingForDoohicky() I have no idea what it is, and Xocde doesn’t help me. You argue above that maybe I don’t need to know the exact type, but often I do if I’m trying to figure out how various components relate to each other, rather than studying the logic of one specific function.

Simon