<div dir="ltr"><p dir="ltr"><br>
</p>
<br><div class="gmail_quote"><div dir="ltr">Fabio Fracassi via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> schrieb am So., 8. Nov. 2015 11:58:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On 07/11/2015 18:18, Richard via cfe-dev wrote:<br>
> [Please reply *only* to the list and do not include my email directly<br>
> in the To: or Cc: of your reply; otherwise I will not see your reply.<br>
> Thanks.]<br>
I thought I did, I explicitly deleted your address from the to field, ...<br>
> In article <<a href="mailto:563DC703.4000507@gmx.net" target="_blank">563DC703.4000507@gmx.net</a>>,<br>
> Fabio Fracassi via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> writes:<br>
><br>
>> Hi,<br>
>><br>
>> On 06/11/2015 19:08, Richard via cfe-dev wrote:<br>
>> [...]<br>
>>> N2541 <<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm</a>><br>
>>> introduced auto and the trailing return type syntax.<br>
>>><br>
>>> Now people are using auto and -> on function signatures where the<br>
>>> return type is stated explicitly anyway. This results in code like:<br>
>>><br>
>>> auto main() -> int<br>
>>> {<br>
>>> return 0;<br>
>>> }<br>
>> so?<br>
>><br>
>>> Srsly? Is this really improving anything over<br>
>>><br>
>>> int main()<br>
>>> {<br>
>>> return 0;<br>
>>> }<br>
>> no, but it is not worse either.<br>
>><br>
>>> To me this is introducing unnecessary clutter<br>
>> it is more uniform,<br>
> It *is* more clutter in the sense that it introduces unnecessary tokens.<br>
From this perspective you are right in calling it clutter.<br>
<br>
> [...]<br>
> design principle) return void. Writing 'auto f() -> void;' obscures<br>
> that this is a command until I get to the end of the declaration. In<br>
> fact writing 'auto' puts me immediately in the mindset of "this<br>
> function is going to return a value" only to make me change my mind<br>
> when I reach the end and learn "oh, the value is void."<br>
Actually for exactly this reason I make an "exception" when using void,<br>
because void is special.<br>
And since void, like auto has exactly four characters it still fits<br>
nicely into the uniformity:<br>
<br>
auto f(int) -> bool; // reads: I have a retun value ... and it is bool<br>
auto f() { return ...; } // reads: I have a return value ... and it is<br>
whatever I return<br>
void g(); // reads: I have no return value<br>
<br>
>> and for mathematically inclined people it is also<br>
>> more natural.<br>
> I didn't know you were appointed spokesman for all mathematically<br>
> inclined people?<br>
Sorry, this was not my intention. IMO the "naturalness" is there because<br>
the mathematical notation of a function is<br>
f: param1_t, param2_t -> return_t<br>
which is closer to<br>
auto f(param1_t, param2_t) -> return_t<br>
>> just because it is a new syntax it doesn't make it more cluttered or<br>
>> anything.<br>
> To me, clutter is adding extra stuff in that's not necessary like<br>
> (void) argument lists or gratuitous use of auto.<br>
To me clutter is something that hinders readability without adding<br>
information.<br>
I think this extra tokens help rather than hinder readability (even if<br>
it does not add information), so I objected to the negative connotation<br>
of "clutter"<br>
>> Herb Sutter recommends this style in his Almost Always Auto article:<br>
> I assume you are talking about this:<br>
> <<a href="http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/" rel="noreferrer" target="_blank">http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/</a>><br>
><br>
> That article is from 2013 and in subsequent talks on YouTube I've<br>
> seen people comment that "whacking everything with an auto hammer"<br>
> doesn't yield the benefits that were claimed at the time. Furthermore,<br>
> just because Herb Sutter likes a certain style doesn't mean that I do.<br>
Sure, I just wanted to show that there are well reasoned people out<br>
there that think differently about this topic.<br>
<br>
This is ultimately a stylistic issue, and thus a matter of taste, which<br>
is hard to discuss. There are (more or less good) reasons to use both<br>
styles, and you can find (more or less good) reasons against each.<br>
<br>
> With clang-tidy we're not talking about the compiler creating a warning<br>
> or error because you use a certain code construct. clang-tidy is<br>
> like clang-format. You don't like LLVM code formatting conventions?<br>
> Nothing's forcing you to use them.<br>
<br>
I wasn't aware that clang-tidy and clang-format were there to<br>
(exclusively) force llvms style, I was under the impression that they<br>
were general tools to clean up code bases to their individual styles.</blockquote><div> </div><div>Just as a side note, clang-tidy supports many checks that are not applicable to llvm, e.g. in the cert, google and cppcoreguideline groups. </div></div></div>