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

[Mehdi AMINI via cfe-dev]

On Sun, Feb 3, 2019 at 6:50 AM Stephen Kelly via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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).


Under the current guidelines, my understanding is that nothing prevents to
use auto in lambda in order to "make the code more readable" when "the type
is already obvious from the context" or "when the type would have been
abstracted away anyways, often behind a container’s typedef such as
std::vector<T>::iterator".

We don't need to update the guideline on auto to be able to use auto in
lambda as soon as c++14 is available.



> 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?
>

I think that multiple people read your proposal and gave feedback on
Phabricator that mandates a revision (for instance for-range loop). Also in
this topic I believe some feedback was given that rewording in order to
remove ambiguity is always good, as long as the "spirit" of the current
rule as it is written is preserved.
So my take on the subject is that we're waiting on a new revision of your
patch?

Best,

-- 
Mehdi




>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190203/948fe688/attachment.html>