<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 05/01/2019 21:56, Mehdi AMINI wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div>You're discounting some
aspects:</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Not surprising! :)</p>
<p>Thanks for your contribution. Lots of things I hadn't considered
here.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>- Code is written
downstream without much
consideration for the
guideline and then
upstreamed</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>I hadn't considered this. Can you either quantify it, or point to
some examples? I guess you're referring to some large commits
which might not have been reviewed for particulars of style. Can
you point me to some?<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div>- Review process isn't
perfect: we let things
slip, we don't always want
to nitpick on things like
`auto`, etc.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Yes, even in that case, the submitter thinks the submitted code
makes sense and the reviewer doesn't think it doesn't make sense.
At least not so much that they'd block a commit because of it :).<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div>- Some developers just
don't know the guidelines
and because of the point
above, some cases slip.<br>
</div>
<div>- People move back and
forth between projects
(i.e. LLVM is not their
main project) and thus
aren't focused on every
details of the code
guidelines (For instance I
would review a patch today
and not necessarily catch
on every style aspect).</div>
<div><br>
</div>
<div>For the particular case
of auto, there is an even
more complex effect: since
the intention is that
"types should be obvious
when reading the code",
someone very familiar with
some libraries will always
unconsciously infer the
returned type from API
calls (from conventions,
past experience, etc.),
but someone who is less
familiar with this area of
the codebase would be
quickly confused.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Intermediate AST Matchers typically look like <br>
</p>
<p> auto ConstrExpr =
cxxConstructExpr(hasType(recordDecl(hasName(ClassName))));<br>
</p>
<p>`auto` is used exclusively when writing AST Matchers variables.
No one complains about not reading the exact type of `ConstrExpr`
in the code. And the people who work on those parts of the code
tend to be the people most against all use of `auto`.</p>
<p><br>
</p>
<p>(You could write `StatementMatcher` instead of `auto` above if
you wished, and `DeclarationMatcher`, `TypeMatcher` etc for other
matchers. Unless you were familiar with all the implementation
details of AST Matchers those type names wouldn't mean anything to
you. In fact, they're not type names - they're just typedefs.
Typedefs are what we used to use before we were able to use auto,
when the actual type doesn't matter. You can look up the actual
expansion of the typedef if you wish, but it won't make the above
code clearer to you, because if you know what AST Matchers are,
the exact type of `ConstrExpr` *does not matter*. Only the concept
matters. It's an AST Matcher and it can be nested inside other AST
Matchers and passed to Finder->addMatcher).</p>
<p><br>
</p>
<p>So, you don't see the exact type, and that doesn't affect your
confusion about the above line. It could be `auto`,
`StatementMatcher` or `internal::Matcher<Stmt>` without
affecting your confusion. If you felt confusion about that line of
code, it wasn't about the type.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">I
claim that this example is
less about `auto` itself but
rather a question about can
you consider that `getAs` is
such a "core" pattern of
this area of the code base
that we can accept as
"common knowledge" that it
always wrap the returned
type in an optional.
<div>And if we do, then the
current guideline is
actually fulfilled: "the
type is already obvious
from the context" (getAs
being part of the context
at this point).</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>We probably don't need to dive into the details here. You will
notice though that the conclusion from the same people who
discussed that revisited it in
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D54877#inline-484380">https://reviews.llvm.org/D54877#inline-484380</a> and concluded
retrospectively that `auto` was fine.<br>
</p>
<p> <br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>There are other such
example, for example I
believe we can assume that
all the standard STL
algorithm are known and so
in this case: </div>
<div>
<div> llvm::all_of(Container,
[] (const auto
&Value) { ...})</div>
</div>
<div> </div>
<div>The use of auto in the
lambda should be OK
(assuming c++14 and the
type of Container is
obvious).</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>If you require that something about the type (either the type
itself or the concept - ie being a container) or the type passed
to the lambda be obvious, you can choose either one. My proposal
for the LLVM guideline is not to make both the container and the
lambda arg `auto`. But you could choose one or the other. I think
you're agreeing with that.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> </p>
<p>For me that means I'm
not able to get my
clang-query features
(<a
class="gmail-m_-3798332382521450953moz-txt-link-freetext"
href="https://steveire.wordpress.com/2018/11/11/future-developments-in-clang-query/"
target="_blank"
moz-do-not-send="true">https://steveire.wordpress.com/2018/11/11/future-developments-in-clang-query/</a>)
upstream because I'm
getting reviews which
say "remove <tt
class="gmail-m_-3798332382521450953remarkup-monospaced">auto</tt>,
here and everywhere in
this file." in</p>
<p><br>
</p>
<p> <a
class="gmail-m_-3798332382521450953moz-txt-link-freetext"
href="https://reviews.llvm.org/D54408?id=173770#inline-480255"
target="_blank"
moz-do-not-send="true">https://reviews.llvm.org/D54408?id=173770#inline-480255</a><br>
</p>
<p><br>
</p>
<p>That's a bit of a
difficult review
comment, given the
ways it is already
used throughout the
code.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<pre class="gmail-m_-3798332382521450953moz-quote-pre">It seems like there is widespread enough acknowledgement that the current state of things is broken, but there is no concrete proposal for a coding standards change. Please prepare a patch so we can discuss it.</pre>
</blockquote>
<p><br>
</p>
<p>I made a proposal in
my initial mail in
this thread. See the
end of the email: <a
class="gmail-m_-3798332382521450953moz-txt-link-freetext"
href="https://lists.llvm.org/pipermail/llvm-dev/2018-November/127953.html"
target="_blank"
moz-do-not-send="true">https://lists.llvm.org/pipermail/llvm-dev/2018-November/127953.html</a></p>
</div>
</blockquote>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Phab is not
well-suited to
discussion like this,
so we should probably
keep it on the mailing
list for now.<br>
</p>
<p><br>
</p>
<p>But, here's some
updated thinking:<br>
</p>
<p><br>
</p>
<p>New guidelines should
<br>
<br>
* Be easy to follow<br>
* Have some
consistency<br>
* Be modern<br>
* Be welcoming (or at
least non-hostile) to
newcomers<br>
* Standardize existing
practice in LLVM<br>
* Achieve a consensus
of support about the
spirit of the
guideline (consensus
is not unanimity) and
be acceptable to
people who dislike
auto<br>
<br>
</p>
<p>Can we agree on that
much to start?<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>It depends what you
mean by "standardize
existing practice in
LLVM", this seems like a
"guideline" to define the
new guideline, more than a
rule. I.e. if some area
are "abusing" auto for
example, this is not
automatically a reason to
standardize, this may just
be an indication that some
cleanup is needed there.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Certainly! I tried to quantify the existing use of `auto` a bit
in a previous email. Can you do a more-useful quantification?<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> </p>
<p><br>
</p>
<p>On the Phab review,
some people expressed
that they liked the
examples of when auto
is acceptable. Here is
an updated attempt at
guideline text for
that section:<br>
</p>
<p><br>
<br>
```<br>
Some are advocating a
policy of "almost
always ``auto``" in
C++11, however LLVM<br>
uses a more moderate
stance. Don't "almost
always" use ``auto``,
but it may be used
where either the
Concept or the type is
obvious from the
context. Here are<br>
some cases where use
of ``auto`` would make
sense:<br>
<br>
* Where the type
appears elsewhere in
the line (eg a
dyn_cast)<br>
* Where the variable
name or initializing
expression provides
enough information
(`auto SR =
getSourceRange()`)<br>
* Where the context
makes the *Concept*
obvious, even if the
type is not obvious
(eg, where the
instance is only used
as an iterator, or in
an algorithm as a
container-like
concept, or only with
a validity check, or
an AST Matcher).<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>The later point isn't
clear to me: even if
you're only using the
instance as an iterator, I
may want to know what
types the iterator is
actually iterating on.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Hmm, the existing guideline says that these iterators are ok as
`auto`. I think you're saying that if there's a reason to have an
exception for a particular iterator then you can have an exception
for it. I agree with that! Are you thinking of some exceptional
case?<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div>I'm not saying that the
idea you have here is not
desirable, just that the
language used does not
help me visualize what is
/ isn't OK: it does not
fit your first criteria
"Be easy to follow".</div>
<div> <br>
</div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> <br>
Exceptions may arise,
but they should only
arise in exceptional
cases. If the case is
not exceptional, apply
the guidelines in
review discussion.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>This last sentence
seems general to the full
document rather than this
section?</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Yes, I'm just trying to satisfy people who might be worried :).<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> ```<br>
</p>
<p><br>
</p>
<p>The most important
thing here is that it
does not accept your
proposal that 'the
type must be obvious'.
Instead, it recognizes
that `auto` is really
"an unspecified
concept" - unspecified
only because we can't
specify the concept in
C++ yet.</p>
<p>However, the
point/concern seems to
be that readers of
code should know the
instance may be used
in its local scope.<br>
</p>
<p>That's why these
guidelines would allow
`auto Ctors` in <br>
</p>
<p><br>
</p>
<p>llvm::Optional<std::pair<std::string,
MatcherCtor>><br>
getNodeConstructorType(ASTNodeKind targetType) {<br>
const auto
&Ctors =
RegistryData->nodeConstructors();<br>
auto It =
llvm::find_if(<br>
Ctors,
[targetType](const
NodeConstructorMap::value_type
&Ctor) {<br>
return
Ctor.first.isSame(targetType);<br>
});<br>
if (It ==
Ctors.end())<br>
return
llvm::None;<br>
return
It->second;<br>
} <br>
<br>
</p>
<p>because `Ctors` is
obviously the
Container *concept*</p>
</div>
</blockquote>
<div>It is only obvious
after your read the
following, but more
importantly: why use auto
here? It wouldn't hurt to
write:
const NodeConstructorMap &Ctors
=
RegistryData->nodeConstructors();
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Why write `NodeConstructorMap`? That's not a type. If the reason
for not using `auto` is that "the type must be obvious", then
surely you're obliged to expand typedefs? `NodeConstructorMap`
could be a std::vector for all you know...</p>
<p><br>
</p>
<p>The only thing you care about is that it's a container. It's a
short function that uses the variable with `llvm::find_if`. Both
the shortness and the use with `find_if` are relevant. This thing
is a container, and I can't think of a container where the precise
type matters in a small algorithmic function like this.</p>
<p><br>
</p>
<p>But the *Container-ness* of it does matter<font size="+1">.</font>
And it is obvious. That's the concept that is obvious, so it
should be allowed by the guidelines and should pass review.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div>I.e. auto does not make
the code more readable to
me in this case.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>`NodeConstructorMap` doesn't "make the type obvious" either.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div>On the other hand, if
the type of Ctors is
explicit, the lambda
argument type could be
auto to me (it becomes
obvious from the local
context and the use of
llvm::find_if).</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Fair enough - I agree that this is a consequence of the guideline
I propose, as I wrote above.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>, and knowing exactly
what type it is is not
necessary in the local
context. </p>
</div>
</blockquote>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> </p>
<p>However, in the below
code it would probably
not be ok because
we're calling methods
on the instance which
opens up more
possibilities (is it a
base interface? etc):</p>
<p><br>
</p>
void SomeClass::foo(int
input)<br>
{<br>
auto Ctors =
getCtors(input);<br>
<br>
m_widgets =
Ctors->calculate();<br>
}<br>
<br>
<p>Here, `Ctors` is
definitely not a
Container concept, we
don't know what kind
of concept it is, so
we should know the
type by seeing it
typed in the code.<br>
</p>
<p>Another example from
earlier in the thread:</p>
<p><br>
</p>
<p> template
<typename BaseT,
typename DerivedT><br>
void
registerIfNodeMatcher(...)
{<br>
auto NodeKind =
ASTNodeKind::getFromNodeKind<DerivedT>();<br>
if
(!NodeKind.isNone())<br>
NodeCtors[NodeKind] =
std::make_pair(MatcherName, Descriptor);<br>
}<br>
<br>
</p>
<p>Here, `NodeKind` is
used as an Optional
(or Maybe) *concept*.
All we do is a
validity check. So,
`auto` should be
allowed here.</p>
<p>This 'the concept
must be obvious'
guideline is also what
allows the use of
`auto` for iterators.<br>
</p>
<p><br>
</p>
<p>What do people think
of "Either the Concept
or the type should be
obvious from the
context" as a baseline
guideline?</p>
</div>
</blockquote>
<div>You forgot to add "and
knowing exactly what type
it is is not necessary in
the local context" after
"Concept", it seems that
this is necessary for your
definition.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Correct! Thanks for the clarification. I mentioned earlier in the
thread various things about use of `auto` being ok where the type
is irrelevant, but indeed I didn't put that in the proposed
guideline and your clarification is useful.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CANF-O=aj2BSb8feKCOwnrKQbjGmwFjea1wtVKp7ijP5NwBN-bQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I'm still fairly
unconvinced, because the
concept of "concept" seems
too fuzzy to be applicable
in such a guideline. What
is a "Concept" other than
a class that honor an API?
How is your previous
example " m_widgets =
Ctors->calculate();"
not just obvious that
Ctors is an instance of a
Concept that "can
calculate a widget"?</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Indeed, but if you go down that path, you arrive at AAA, and I
don't want to propose that. I said that in the first line of this
thread, but expressing the reason for that in terms of Concepts
clarifies the reason for that in my mind. So, thanks for the
discussion!<br>
</p>
<p><br>
</p>
<p>There are more general concepts, such as Iterator (ie if you see
this being used in a raw for loop or to compare with the result of
an algorithm it is not surprising), Container/Range (ie, if this
is passed directly to a range-capable algorithm such as find_if,
it is not surprising), Optional/Maybe (if all we do in the local
context of the `auto var` is check for validity and then pass the
variable to something else - a function, a container etc - that is
not surprising).</p>
<p>Isn't there something more 'core' about those than 'has a foo()
method returning int'? Don't they occur very often?<br>
</p>
<p>Thanks,</p>
<p>Stephen.</p>
<p><br>
</p>
</body>
</html>