> On Jan 10, 2017, at 9:03 PM, Darin Adler <da...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
