04 янв. 2014 г., в 9:51, Darin Adler <da...@apple.com> написал(а):
> 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. Not sure if this is a fair comparison. Type names are useful when trying to understand what the code is doing. You get verified information about what each "thingy" in the code is, and extensive tools support for cross-referencing (be it Cmd-click, or copy/paste and grep). Inline and virtual specifiers might perhaps be useful for performance work, where reading the code shouldn't be the primary source of information anyway. > 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. To be clear, I'm not arguing to ban auto. Geoff's proposed WebKit style rules addition is one I like. However this example that you gave in support of auto seems to me like a reason to completely ban it, one I didn't think of before. As auto facilitates search-replace-don't-read refactoring, we'll just end up with rotten code like // Obsolete comment. auto preRefactoringVariableName = postRefactoringFunction(); These lines will be visible in the patch, and a super careful reviewer could catch it. Overall, it would strain reviewers more, I think. - WBR, Alexey Proskuryakov _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
