[webkit-dev] When to use auto? (I usually consider it harmful)

[Geoffrey Garen]

Hi folks.

Recently, I’ve seen patches go by using the C++11 “auto” keyword. For example, 
let me pick on Andreas:

 http://trac.webkit.org/changeset/161143
 
 +auto newRenderer = textNode.createTextRenderer(style);
 +ASSERT(newRenderer);
 
 ….
 
 +parentRenderer-addChild(newRenderer.leakPtr(), nextRenderer);

I think this use of “auto” is net harmful. 

Upsides:

- Less typing

Downsides:

- I don’t know the type of ’newRenderer’ at a glance
- Navigating to newRenderer’s class definition is a two-step process: (1) Go to 
the definition of createTextRenderer and see what it returns; (2) Go to the 
definition of (1).

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.

I think an appropriate style guideline for “auto” would say something like:

- Use “auto to declare a disgusting templated iterator type in a loop
- Use “auto… - to define a template-dependent return type in a class template
- In all other cases, use an explicit type declaration

Thoughts?

Thanks,
Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Filip Pizlo]

On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.
 
 Recently, I’ve seen patches go by using the C++11 “auto” keyword. For 
 example, let me pick on Andreas:
 
 http://trac.webkit.org/changeset/161143
 
 +auto newRenderer = textNode.createTextRenderer(style);
 +ASSERT(newRenderer);
 
 ….
 
 +parentRenderer-addChild(newRenderer.leakPtr(), nextRenderer);
 
 I think this use of “auto” is net harmful. 
 
 Upsides:
 
 - Less typing
 
 Downsides:
 
 - I don’t know the type of ’newRenderer’ at a glance
 - Navigating to newRenderer’s class definition is a two-step process: (1) Go 
 to the definition of createTextRenderer and see what it returns; (2) Go to 
 the definition of (1).
 
 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.

I agree.

Code is read more than it is written.  In many cases, the types of variables - 
even nasty templated ones - convey useful information that makes the code 
easier to read.  I think that auto is only a good idea if the presence of the 
full type would be either completely redundant or would make the code hard to 
read by virtue of being unusually long (80 chars, like some intense HashMap 
instantiations).  Crucially, while the C++ compiler has a smart type inference 
engine that can see a lot of code all at once, a typical human reader lacks 
such powers and so auto results in a net loss of information.

 
 I think an appropriate style guideline for “auto” would say something like:
 
 - Use “auto to declare a disgusting templated iterator type in a loop
 - Use “auto… - to define a template-dependent return type in a class 
 template
 - In all other cases, use an explicit type declaration
 
 Thoughts?

I like this.  I would like to see this be added to the style guide.

-Filip

 
 Thanks,
 Geoff
 ___
 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

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Dan Bernstein]

On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.
 
 Recently, I’ve seen patches go by using the C++11 “auto” keyword. For 
 example, let me pick on Andreas:
 
 http://trac.webkit.org/changeset/161143
 
 +auto newRenderer = textNode.createTextRenderer(style);
 +ASSERT(newRenderer);
 
 ….
 
 +parentRenderer-addChild(newRenderer.leakPtr(), nextRenderer);
 
 I think this use of “auto” is net harmful. 
 
 Upsides:
 
 - Less typing
 
 Downsides:
 
 - I don’t know the type of ’newRenderer’ at a glance
 - Navigating to newRenderer’s class definition is a two-step process: (1) Go 
 to the definition of createTextRenderer and see what it returns; (2) Go to 
 the definition of (1).
 
 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.

We tend to avoid local write-once-read-once local variables, i.e. we tend to 
prefer

{
setSize(optimalSize());
}

to

{
CGSize newSize = optimalSize();
setSize(newSize);
}

But the up- and down-sides of this are the same as those of using auto. Do you 
think we should also encourage use of write-once-read-once locals for the same 
reasons?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Alexey Proskuryakov]

02 янв. 2014 г., в 13:12, Geoffrey Garen gga...@apple.com написал(а):

 I think an appropriate style guideline for “auto” would say something like:
 
 - Use “auto to declare a disgusting templated iterator type in a loop
 - Use “auto… - to define a template-dependent return type in a class 
 template
 - In all other cases, use an explicit type declaration

+1

What do you think about these examples?

auto failureCallback = [promiseWrapper]() mutable {
promiseWrapper.reject(nullptr);
};

…

auto iter = m_nameToIdentifierMap.find(name.isolatedCopy());
if (iter == m_nameToIdentifierMap.end())
return false;

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Brendan Long]

On Thu, 2014-01-02 at 13:12 -0800, Geoffrey Garen wrote:


 I think an appropriate style guideline for “auto” would say something like:
 
 - Use “auto to declare a disgusting templated iterator type in a loop
 - Use “auto… - to define a template-dependent return type in a class 
 template
 - In all other cases, use an explicit type declaration


It would be nice if we could use this with Type::create() functions too,
like:

auto track = AudioTrackPrivateGStreamer::create(...);

Unfortunately the type would be PassRefPtr, not RefPtr, which would
probably not be what we want. Maybe we could do it by just removing
PassRefPtr and adding a move constructor to RefPtr?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Filip Pizlo]

On Jan 2, 2014, at 1:40 PM, Dan Bernstein m...@apple.com wrote:

 
 On Jan 2, 2014, at 1:12 PM, Geoffrey Garen gga...@apple.com wrote:
 
 Hi folks.
 
 Recently, I’ve seen patches go by using the C++11 “auto” keyword. For 
 example, let me pick on Andreas:
 
 http://trac.webkit.org/changeset/161143
 
 +auto newRenderer = textNode.createTextRenderer(style);
 +ASSERT(newRenderer);
 
 ….
 
 +parentRenderer-addChild(newRenderer.leakPtr(), nextRenderer);
 
 I think this use of “auto” is net harmful. 
 
 Upsides:
 
 - Less typing
 
 Downsides:
 
 - I don’t know the type of ’newRenderer’ at a glance
 - Navigating to newRenderer’s class definition is a two-step process: (1) Go 
 to the definition of createTextRenderer and see what it returns; (2) Go to 
 the definition of (1).
 
 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.
 
 We tend to avoid local write-once-read-once local variables, i.e. we tend to 
 prefer
 
 {
setSize(optimalSize());
 }
 
 to
 
 {
CGSize newSize = optimalSize();
setSize(newSize);
 }
 
 But the up- and down-sides of this are the same as those of using auto. Do 
 you think we should also encourage use of write-once-read-once locals for the 
 same reasons?

This is an interesting analogy.  In the past, I have used write-once-read-once 
locals in order to explicitly expose the variable's type.  On the other hand, 
omitting the temporary variable can increase readability by removing noise.  
Probably, it's usually better to omit write-once-read-once variables, and so 
that should probably be a style suggestion.  I don't think we should change 
this.

I think the goal should be that if you do introduce a temporary variable for 
some reason, then being explicit about its type is better.  Consider that in 
your second example, there might be 200 lines of code between the call to 
optimalSize() and the call to setSize().  I that case, we're essentially 
choosing between having the code reader see this:

auto newSize = optimalSize();

or this:

CGSize newSize = optimalSize();

If I'm trying to grok this code, I will be looking for any hint I can find to 
determine what the heck newSize is.  In the first version, I just know that 
it's called newSize and that it's the result of calling a function called 
optimalSize().  In the second version, I know all of those facts, plus I know 
that it's a CGSize.  That's one more bit of information that I can use to build 
up my intuition about the code.  And in this case, I get that extra information 
with just two more characters of typing.

On the other hand, I do agree that:

setSize(optimalSize())

is the best: in this case I'm not going to even think about any temporary 
variables because I already know what the code is doing just by looking at it.  
But it's not always possible to write the code that way even if the variable is 
write-once-read-once.  For example, in the 200 lines of code between the call 
to optimalSize() and the call to setSize(), I might clobber the state necessary 
to compute optimalSize().

So, to me, the policy should be: *if* you already have to have a variable for 
something *then* you should prefer to be explicit about its type.

-Filip


 ___
 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

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Brent Fulgham]

On Jan 2, 2014, at 1:54 PM, Filip Pizlo fpi...@apple.com wrote:

 I think the goal should be that if you do introduce a temporary variable for 
 some reason, then being explicit about its type is better.  Consider that in 
 your second example, there might be 200 lines of code between the call to 
 optimalSize() and the call to setSize().  I that case, we're essentially 
 choosing between having the code reader see this:
 
 auto newSize = optimalSize();
 
 or this:
 
 CGSize newSize = optimalSize();

I’m not sure that having the temporary created 200 lines before it was used 
would be improved with either of these cases! ;-)

Allowing the compiler to infer type seems like a big win, for all the same 
reasons it is for SML and other Hindley-Milner languages. Why must I manually 
enter stuff that the compiler should be able to determine for me?

Our development environments should be capable of showing us the resulting 
‘auto’ type, so I feel like requiring explicit type declarations are a step 
backwards.

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Adam Roben]

I found 
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
very persuasive in my thinking about when to use auto.

-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Filip Pizlo]

On Jan 2, 2014, at 1:59 PM, Brent Fulgham bfulg...@apple.com wrote:

 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.

I can comment about the Ruby code.  It's often hard to make sense of that code 
because you don't have variable types to give you hints about what you're 
looking at.  For example, this treasure, from display-profiler-output:

compilation.descriptions.each {
| description |
if description.origin.index {
| myBytecode |
bytecodes == myBytecode.bytecodes
}
myOrigins  description.origin
end
}

It's true that compilation points to a Compilation.  But what does 
descriptions point to?  It turns out that it's an array of CompiledBytecode 
objects.  This is a relevant piece of information because it tells you what 
kinds of information each element in the array contains.  You can figure this 
out if you search for all of the places that the descriptions array gets 
populated.  But, there is no way to see this from looking at the declaration of 
compilation or descriptions.  In the C++ code we would write prior to 
C++11, we would have likely done this as follows:

for (unsigned i = 0; i  compilation-descriptions().size(); ++i) {
CompiledBytecode description = compilation-descriptions()[i];
... // more stuff
}

I find this kind of thing easier to understand, when I have to return to such 
code after possibly a year, or more, of looking at it.  It's code like this 
that makes me think that 'auto'-everywhere is net harmful.

-Filip


 
 -Brent
 ___
 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

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Geoffrey Garen]

 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

This argument is a red herring for two reasons:

(1) The example under consideration does not return an integer.

(2) The compiler warns about implicit integer truncation, and does not allow 
implicit truncation from int64 to int32 without a cast.

 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.

To the contrary, we have never built anything the size of WebKit using Python.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Geoffrey Garen]

 We tend to avoid local write-once-read-once local variables, i.e. we tend to 
 prefer
 
 {
setSize(optimalSize());
 }
 
 to
 
 {
CGSize newSize = optimalSize();
setSize(newSize);
 }
 
 But the up- and down-sides of this are the same as those of using auto.

I think I basically agree with Phil here, and slightly disagree with your 
premise that the upsides and downsides are truly the same:

(1) The downside to explicit declaration in this case is greater because it 
requires an extra line of code.

(2) The upside to explicit declaration in this case is lesser because the value 
is used only once, and in a guaranteed trivial way (just passing it somewhere 
else).

 Do you think we should also encourage use of write-once-read-once locals for 
 the same reasons?

No, not in general.

However, in rare cases, I think the balance shifts, and I do prefer an extra 
line of code for write-once-read-once variables. For example:

int documentWidth = screenWidth(); // The size of the document is equal to the 
size of the screen because…
layout(documentWidth);

In this case, the caller of screenWidth() is changing its meaning, and I 
slightly prefer to call that out.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Geoffrey Garen]

 What do you think about these examples?
 
 auto failureCallback = [promiseWrapper]() mutable {
 promiseWrapper.reject(nullptr);
 };

Here I think auto is good because the type is disgusting to write out by hand, 
and because the type is clearly visible on the right hand side of the 
expression.

 auto iter = m_nameToIdentifierMap.find(name.isolatedCopy());
 if (iter == m_nameToIdentifierMap.end())
 return false;

Here I think auto is good because it likely meets the disgusting templated 
iterator type” clause — even though it’s not in a loop.

Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Brent Fulgham]

Hi Adam,

On Jan 2, 2014, at 2:08 PM, Adam Roben aro...@webkit.org wrote:

 I found 
 http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
 very persuasive in my thinking about when to use auto.

I think this does a much better job of explaining the benefits of ‘auto’ than I 
was able to come up with.

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Filip Pizlo]

I think that this article is one of many great examples of arguments in favor 
of less explicit typing.  These lines of reasoning are often used by proponents 
of both dynamic languages (like Ruby) and type-inferred languages (like ML or 
Haskell).  C++'s auto is almost exactly like what ML and Haskell have and it's 
not surprising to me to see bloggers rehash these decades-old arguments.

But what I like about how we use C++ in WebKit is that we avoid writing English 
comments, and try to document our code using types, function names, and 
variable names.  Types are a particularly powerful form of documentation 
because it is checked by the compiler.  I think that the main source of my 
distaste for using auto everywhere is that it takes away our compiler-checked 
documentation.

The article seems to suggest that we should say:

auto x = type { expression };

when we want documentation.  But this is more noisy than saying:

type x = expression;

I don't think that the auto-based type expression suggested by the article has 
any merits over the traditional variable type.

-Filip


On Jan 2, 2014, at 2:31 PM, Brent Fulgham bfulg...@apple.com wrote:

 Hi Adam,
 
 On Jan 2, 2014, at 2:08 PM, Adam Roben aro...@webkit.org wrote:
 
 I found 
 http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
 very persuasive in my thinking about when to use auto.
 
 I think this does a much better job of explaining the benefits of ‘auto’ than 
 I was able to come up with.
 
 -Brent
 
 ___
 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

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Brent Fulgham]

Hi Filip,

Coming back to your earlier example:

 auto newSize = optimalSize();
 vs:
 CGSize newSize = optimalSize();

If I understand your argument, you feel that the explicit CGSize declaration 
helps the reader because it makes the return value of optimalSize() explicit.

However, that declaration is only stating the type that the author *thinks* 
optimalSize() returns.  There is nothing to guarantee that optimalSize() 
returns a CGSize; only that it returns something that the compiler can turn 
into a CGSize through some set of casts.

The code stating CGSize could have been correct at one point, but the return 
type of optimalSize might have been changed to some similar type without anyone 
noticing.

Using ‘auto’ doesn’t seem to make this situation any worse.

In fact, although Sutter’s suggestion of:

auto newSize = CGSize { optimalSize(); }

looks gross to my eye, it might be a useful approach because it would force the 
compiler to complain if we were returning something that was not explicitely a 
CGSize type.

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Geoffrey Garen]

One interesting point in this article, which I tend to agree with, is that it 
seems generally appropriate to use “auto” in any line of code that already 
conveys type. For example:

(1) Lambda, as pointed out by Alexey:

auto failureCallback = [promiseWrapper]() mutable {
promiseWrapper.reject(nullptr);
};

(2) Integer declaration:

auto x = 42ul;

(3) Simple heap allocation:

auto buffer = std::make_uniqueUniChar[](length);

So, I’d add that to the list of places to use “auto”:

- Use “auto to declare an iterator type
- Use “auto… - to define a template-dependent return type in a class template
- Use “auto” when the right hand side of the expression already denotes type
- In all other cases, use an explicit type declaration

But I’m not convinced by the article’s conclusion that we should just use auto 
everywhere, and use auto x = type{ init }” when we want to commit to a 
specific type. I think that solution would open up a can of worms. Reasonable 
people would routinely disagree about exactly which lines of code needed to 
“commit to a specific type”. A style guide should be as black-and-white as 
possible. “… when we want to …” is basically a cop out for a style guide.

I’m also not convinced by the article’s generalization from a simple 
algorithmic helper function to a whole code base. Algorithmic helper functions 
can, indeed, be written in terms of generic well-known names. I guess that’s 
why I think that iterators should be auto: “begin, “end, “*”, “-” and “++ 
are about as well-known as it gets. But not all problems are simple 
general-purpose algorithms with well-known names. Many problems require you to 
think explicitly about the data. And I’d rather not add statements about data 
to our names, a la Hungarian (sic) notation.

Geoff

On Jan 2, 2014, at 2:08 PM, Adam Roben aro...@webkit.org wrote:

 I found 
 http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
 very persuasive in my thinking about when to use auto.
 
 -Adam
 ___
 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

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Filip Pizlo]

On Jan 2, 2014, at 2:55 PM, Brent Fulgham bfulg...@apple.com wrote:

 Hi Filip,
 
 Coming back to your earlier example:
 
 auto newSize = optimalSize();
 vs:
 CGSize newSize = optimalSize();
 
 If I understand your argument, you feel that the explicit CGSize declaration 
 helps the reader because it makes the return value of optimalSize() explicit.
 
 However, that declaration is only stating the type that the author *thinks* 
 optimalSize() returns.  There is nothing to guarantee that optimalSize() 
 returns a CGSize; only that it returns something that the compiler can turn 
 into a CGSize through some set of casts.

Yes, C++ offers some interesting escape hatches from the type-system so this 
documentation (i.e. the use of CGSize to ascribe a type to newSize) needs to 
be interpreted carefully.  It's not guaranteeing that optimalSize() returns a 
CGSize, only that it returns something that is coercible to a CGSize.  Also, it 
does guarantee that newSize is indeed a CGSize and not anything else.

To me, that's still better than no information at all, which is what auto 
does.

 
 The code stating CGSize could have been correct at one point, but the return 
 type of optimalSize might have been changed to some similar type without 
 anyone noticing.
 
 Using ‘auto’ doesn’t seem to make this situation any worse.

It conveys zero information, whereas declaring the variable as CGSize does 
convey meaningful information about optimalSize(), newSize, and the kinds of 
things you could do with newSize.

 
 In fact, although Sutter’s suggestion of:
 
   auto newSize = CGSize { optimalSize(); }
 
 looks gross to my eye, it might be a useful approach because it would force 
 the compiler to complain if we were returning something that was not 
 explicitely a CGSize type.

I know this doesn't apply to CGSize, but the approach we've been using in JSC 
is to make all unary constructors 'explicit' and to prefer wrapper classes over 
typedefs, even for primitive values.  This also has the effect of preventing 
many implicit coercions, and it carries some other benefits also:

1) It means that you don't have to use this gross syntax.

2) It controls the kind of coercions that can happen even in cases where there 
is no variable, like setSize(optimalSize()).

-Filip


 
 -Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Karen Shaeffer]

On Thu, Jan 02, 2014 at 01:12:46PM -0800, Geoffrey Garen wrote:
 Hi folks.
 
 Recently, I’ve seen patches go by using the C++11 “auto” keyword. For 
 example, let me pick on Andreas:
 
  http://trac.webkit.org/changeset/161143
  
  +auto newRenderer = textNode.createTextRenderer(style);
  +ASSERT(newRenderer);
  
  ….
  
  +parentRenderer-addChild(newRenderer.leakPtr(), nextRenderer);
 
 I think this use of “auto” is net harmful. 
 
 Upsides:
 
 - Less typing
 
 Downsides:
 
 - I don’t know the type of ’newRenderer’ at a glance
 - Navigating to newRenderer’s class definition is a two-step process: (1) Go 
 to the definition of createTextRenderer and see what it returns; (2) Go to 
 the definition of (1).
 
 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.
 
 I think an appropriate style guideline for “auto” would say something like:
 
 - Use “auto to declare a disgusting templated iterator type in a loop
 - Use “auto… - to define a template-dependent return type in a class 
 template
 - In all other cases, use an explicit type declaration
 
 Thoughts?

Hi Geoffrey,
I prefer to write types out, because it does help with understanding the code 
you are
working with. Although there are instances where auto is supposedly required, 
if you
want to write portable c++11 code. My understanding is you should use auto for 
named
lambdas, else the code won't be portable. I've never verified that, but I've
heard that is the case.

enjoy,
Karen
-- 
Karen Shaeffer Be aware: If you see an obstacle in your path,
Neuralscape Services   that obstacle is your path.Zen proverb
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Ryosuke Niwa]

On Thu, Jan 2, 2014 at 4:12 PM, Geoffrey Garen gga...@apple.com wrote:

 I think an appropriate style guideline for “auto” would say something like:

 - Use “auto to declare a disgusting templated iterator type in a loop
 - Use “auto… - to define a template-dependent return type in a class
 template
 - In all other cases, use an explicit type declaration

 Thoughts?


I support this.


On Thu, Jan 2, 2014 at 5:55 PM, Brent Fulgham bfulg...@apple.com wrote:

 Coming back to your earlier example:

 auto newSize = optimalSize();
 vs:

 CGSize newSize = optimalSize();


 If I understand your argument, you feel that the explicit CGSize
 declaration helps the reader because it makes the return value of
 optimalSize() explicit.


It also clarifies that newSize is, indeed, CGSize.  It's often useful to
clarify the type of a local variable.

However, that declaration is only stating the type that the author *thinks*
 optimalSize() returns.  There is nothing to guarantee that optimalSize()
 returns a CGSize; only that it returns something that the compiler can turn
 into a CGSize through some set of casts.



The code stating CGSize could have been correct at one point, but the
 return type of optimalSize might have been changed to some similar type
 without anyone noticing.


This is why we have the following style guideline:
https://www.webkit.org/coding/coding-style.html#classes-explicit
Use a constructor to do an implicit conversion when the argument is
reasonably thought of as a type conversion and the type conversion is fast.
Otherwise, use the explicit keyword or a function returning the type. This
only applies to single argument constructors.

Having said that, I can see there could be cases where auto is more
appropriate because we want to match the type of whatever function we're
calling e.g. inside a template.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

[Maciej Stachowiak]

On Jan 2, 2014, at 2:48 PM, Filip Pizlo fpi...@apple.com wrote:

 I think that this article is one of many great examples of arguments in favor 
 of less explicit typing.  These lines of reasoning are often used by 
 proponents of both dynamic languages (like Ruby) and type-inferred languages 
 (like ML or Haskell).  C++'s auto is almost exactly like what ML and Haskell 
 have and it's not surprising to me to see bloggers rehash these decades-old 
 arguments.
 
 But what I like about how we use C++ in WebKit is that we avoid writing 
 English comments, and try to document our code using types, function names, 
 and variable names.  Types are a particularly powerful form of documentation 
 because it is checked by the compiler.  I think that the main source of my 
 distaste for using auto everywhere is that it takes away our compiler-checked 
 documentation.
 
 The article seems to suggest that we should say:
 
 auto x = type { expression };
 
 when we want documentation.  But this is more noisy than saying:
 
 type x = expression;
 
 I don't think that the auto-based type expression suggested by the article 
 has any merits over the traditional variable type.

It does have one merit, namely once you've typed auto you can't accidentally 
forget to intialize the variable. Other than that, it seems like a stretch.

I can see some advantages to mostly type-free coding, but I think it's too big 
a change in style to our code base to make all at once. I'd rather start with 
something like Geoff's guidelines, where we use 'auto' only in cases where the 
type is too ugly to spell out, or already effectively stated by the line of 
code.

I'm not sure I like 'auto x = 42ul' over 'unsigned long x = 42' though. It 
effectively still has a type declaration but it's just using a short and 
slightly mysterious synonym for it. I don't think that is helpful on th whole.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev