> 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 = make_foo();
>>> aut
>> 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.
>
>> 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
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 that are probably not
> 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 very limited rules tha
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 that are probably not
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 usi
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 =
> 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: if the type is obvio
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:
>
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 =
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 structures and alg
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
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 wrote:
>
> OK, you d
> 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 type of the expres
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
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
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 == mapping.end()) {
>>// With
> 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 that we previously built
> th
>> 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
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 readabilit
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
> 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 time if countOfThing is unsigned
>
> I und
>
> 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 list
> 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 certain this is a bad thi
> 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 you don’t like “aut
26 matches
Mail list logo
