[llvm-dev] RFC: Modernizing our use of auto

Stephen Kelly via llvm-dev llvm-dev at lists.llvm.org
Sun Feb 3 06:49:44 PST 2019


On 31/12/2018 04:54, Chris Lattner via llvm-dev wrote:
>> Do those uses conform to the guide? If they don't, then should the guide be updated? Are the types there 'obvious’?
> 
> If/when we revise the policy, then it would make sense for non-conforming uses of auto to be changed.  However, I don’t think that actually making a widespread change would be high priority...
> 
>> How did all of those uses get into the codebase? Does it indicate that the guide is not followed, or does it indicate that the guide is too subjective, or that maybe the 'the type must be obvios' guide does not reflect the 'reality at the coalface' anymore? Should those uses of auto be changed?
> 
> My understanding is that there has been no widely understood or accepted policy, so different coders and reviewers are doing different things.

One of the things which has no consensus here is whether 'auto' may be
used in lambdas (using c++-14). This feature was celebrated as a big
feature which gets unlocked by migrating to toolchains which provide
that feature:

  https://groups.google.com/forum/#!msg/llvm-dev/0VkIuhn10nE/QZ5FwYEmHAAJ

So, does this need a guideline update?

Is there consistency in celbrating that but writing 'remove all use of
auto from this file' in reviews?

If there's no consensus and no consistency, what does that mean for the
code?

Is

   if (const auto *TSI = D->getTypeSourceInfo())

ok?

Some reviewers say 'no'. What is the consensus and how is that expressed
in the guidelines?

Does anyone have any interest in making the guidelines more clear on
this?

I have made several proposals, and at least Chris agreed that something
should be improved, but then he left the discussion.

Does anyone else think that something can be improved? Is anyone willing
to read and comment on my proposal and get a change to the guidelines
committed?

The original email in this thread was about how to handle features that
become 'unlocked' by updates to our minimum toolchain requirements. That
is now upon us.

Thanks,

Stephen.



More information about the llvm-dev mailing list