Hi, On Jan 2, 2014, at 1:12 PM, Geoffrey Garen <gga...@apple.com> wrote:
>> + auto newRenderer = textNode.createTextRenderer(style); >> + ASSERT(newRenderer); >> >> …. >> >> + parentRenderer->addChild(newRenderer.leakPtr(), nextRenderer); > > I think this use of “auto” is net harmful. I disagree. I think the use of auto is an improvement, because it makes it less likely that we have something like the following: int wrong = something.get64BitInt(); // potential truncation There are plenty of cases where we change the signature of functions from one type to another, sometimes promoting sizes. I haven’t seen us do a very consistent job of combing through sources to make sure all receiving variables are properly sized. When we don’t use ‘auto’, we run the risk of assigning to variables that the compiler “makes work” by casting. We only know this is happening when the compiler generates a warning (and we look for that warning). > I think the downsides outweigh the upsides here because reading code is more > common than writing code, and because it’s not *that* much typing to write > out "RenderPtr< RenderText>”. In this particular code, I think it’s > especially bad to disguise the type of a pointer in the render tree, since > we’re in the middle of a transition to a new type of pointer, and so it’s > important to know if you’re looking at code that does the new thing or the > old thing. Don’t we have this same problem with all of our JavaScript, Python, and Ruby code? We don’t have type specifications in those languages, but we manage to build large software with them as well. -Brent _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
