Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 12, 2017, at 10:37 AM, Geoffrey Garen wrote: > >>> e.g. I think this is great: >>> auto ptr = std::make_unique(bar); >>> Proposed rule: if the type is obvious because it's on the line, then auto >>> is good. >>> Similarly: >>> auto i = static_cast(j); >>> auto foo =

Re: [webkit-dev] [webkit-reviewers] usage of auto

>> My take-away from this discussion so far is that there is actually very >> little consensus on usage of auto, which means there’s probably very little >> room for actual style guideline rules. >> >> I think there are two very limited rules that are probably not objectionable >> to anybody.

Re: [webkit-dev] [webkit-reviewers] usage of auto

>> e.g. I think this is great: >> auto ptr = std::make_unique(bar); >> Proposed rule: if the type is obvious because it's on the line, then auto is >> good. >> Similarly: >> auto i = static_cast(j); >> auto foo = make_foo(); >> auto bar = something.get_bar(); // Sometimes, "bar" is obvious. > I'm

Re: [webkit-dev] [webkit-reviewers] usage of auto

12.01.2017, 19:54, "Brady Eidson" : > My take-away from this discussion so far is that there is actually very > little consensus on usage of auto, which means there’s probably very little > room for actual style guideline rules. > > I think there are two very limited rules

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 12, 2017, at 08:54, Brady Eidson wrote: > > My take-away from this discussion so far is that there is actually very > little consensus on usage of auto, which means there’s probably very little > room for actual style guideline rules. > > I think there are two

Re: [webkit-dev] [webkit-reviewers] usage of auto

12.01.2017, 19:54, "Brady Eidson" : > My take-away from this discussion so far is that there is actually very > little consensus on usage of auto, which means there’s probably very little > room for actual style guideline rules. > > I think there are two very limited rules

Re: [webkit-dev] [webkit-reviewers] usage of auto

My take-away from this discussion so far is that there is actually very little consensus on usage of auto, which means there’s probably very little room for actual style guideline rules. I think there are two very limited rules that are probably not objectionable to anybody. 1 - If you are

Re: [webkit-dev] [webkit-reviewers] usage of auto

Hi, O Mér, 11-01-2017 ás 11:15 -0800, JF Bastien escribiu: > e.g. I think this is great: > auto ptr = std::make_unique(bar); > Proposed rule: if the type is obvious because it's on the line, then > auto is good. > Similarly: > auto i = static_cast(j); > auto foo = make_foo(); > auto bar =

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 11, 2017, at 11:15 AM, JF Bastien wrote: > > Would it be helpful to focus on small well-defined cases where auto makes > sense, and progressively grow that list as we see fit? > > > e.g. I think this is great: > auto ptr = std::make_unique(bar); > Proposed rule:

Re: [webkit-dev] [webkit-reviewers] usage of auto

Perhaps we need to be especially careful about replacing Refs and RefPtrs with auto. It was mentioned that using typedefs to hide pointer types is often the source of serious bugs. A similar rule could apply to using auto with smart pointers. On Wed, 2017-01-11 at 09:43 -0800, Darin Adler wrote:

Re: [webkit-dev] [webkit-reviewers] usage of auto

Would it be helpful to focus on small well-defined cases where auto makes sense, and progressively grow that list as we see fit? e.g. I think this is great: auto ptr = std::make_unique(bar); Proposed rule: if the type is obvious because it's on the line, then auto is good. Similarly: auto i =

Re: [webkit-dev] [webkit-reviewers] usage of auto

11.01.2017, 21:55, "Geoffrey Garen" : > I’m open to auto, but skeptical. > > (1) Research-ability. I read a lot of code that is new to me, that I have > never written. I find type statements to be useful as documentation for where > to look for more information about how data

Re: [webkit-dev] [webkit-reviewers] usage of auto

I’m open to auto, but skeptical. (1) Research-ability. I read a lot of code that is new to me, that I have never written. I find type statements to be useful as documentation for where to look for more information about how data structures and algorithms relate to each other. Traversing a tree

Re: [webkit-dev] [webkit-reviewers] usage of auto

I'm only arguing for why using auto would be bad in the code snippet that we were talking about. My views regarding auto in other code are not strong. I only object to using auto when it is dropping useful information. -Filip > On Jan 11, 2017, at 9:15 AM, Darin Adler

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 11, 2017, at 9:41 AM, Alexey Proskuryakov wrote: > > In a way, these are read-time assertions. Exactly. A type name is a read-time assertion of the specific type that a variable has and “auto” is a read-time assertion that the type of the variable is the same as the

Re: [webkit-dev] [webkit-reviewers] usage of auto

There are two considerations which make me skeptical that auto is a good thing. 1. There are many smart pointer types in C++, and ignoring pointer types is very error prone. Others have mentioned std::optional, and mistakes being made with RefPtrs. I even saw a case where a review comment that

Re: [webkit-dev] [webkit-reviewers] usage of auto

OK, you didn’t convince me but I can see that your opinions here are strongly held! — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

On Jan 10, 2017, at 23:49, Darin Adler wrote: >> On Jan 10, 2017, at 10:17 PM, Filip Pizlo wrote: >> >>while (Arg src = worklist.pop()) { >>HashMap::iterator iter = >> mapping.find(src); >>if (iter

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 10, 2017, at 10:17 PM, Filip Pizlo wrote: > > while (Arg src = worklist.pop()) { > HashMap::iterator iter = > mapping.find(src); > if (iter == mapping.end()) { > // With a shift it's possible

Re: [webkit-dev] [webkit-reviewers] usage of auto

>> I’d love to see examples where using auto substantially hurts readability so >> we could debate them. I once saw a RefPtr changed to auto in some generated code where it was unclear what the return type was. For at least one generated instance the return type was Something* that needed a

Re: [webkit-dev] [webkit-reviewers] usage of auto

Brady asked: > Have you identified any situation where explicitly calling out the type in a > range-based for loop has been better than using the proper form of auto? > Have you identified a situation where explicitly calling out a nasty > templated type, like in my example, added to

Re: [webkit-dev] [webkit-reviewers] usage of auto

I usually like using auto / auto* as much as possible. The one exception where I have found using auto confusing was for functions returning an std::optional. E.g. auto value = maximum(); if (!value) return; I find that the check is confusing because it returns early if value is 0 in the

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 10, 2017, at 9:49 PM, Darin Adler wrote: > >> On Jan 10, 2017, at 9:46 PM, Simon Fraser wrote: >> >> auto countOfThing = getNumberOfThings(); >> ASSERT(countOfThing >= 0); // Can’t tell by reading whether the ASSERT is >> assured at compile

Re: [webkit-dev] [webkit-reviewers] usage of auto

> > auto thingLength = getLengthOfThing(); > IntSize size(thingLength, 2); // Can’t tell by reading if thingLength is > LayoutUnit or float and thus truncated here. > The same is true for: int thingLength = getLengthOfThing(); ___ webkit-dev mailing

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 10, 2017, at 9:46 PM, Simon Fraser wrote: > > auto countOfThing = getNumberOfThings(); > ASSERT(countOfThing >= 0); // Can’t tell by reading whether the ASSERT is > assured at compile time if countOfThing is unsigned I understand wanting to know, but I am not

Re: [webkit-dev] [webkit-reviewers] usage of auto

> On Jan 10, 2017, at 9:03 PM, Darin Adler 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