I realize that I am resisting change, and also that the WebKit community would never agree to completely forbid a useful language feature, but I like to err on the more explicit side of coding. It is hard to say "does this make the code cleaner more than it removes useful information?" or "will this cause problems for other developers?" with a style guideline.
Alex Christensen > On Jan 4, 2014, at 10:51 AM, Darin Adler <da...@apple.com> wrote: > > >> 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 > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
