<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 10:42 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=dblaikie@gmail.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, May 2, 2014 at 9:40 AM, Philip Reames <<a href="mailto:listmail@philipreames.com" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=listmail@philipreames.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">listmail@philipreames.com</a>> wrote:<br>

><br>
> On 05/02/2014 02:18 AM, David Chisnall wrote:<br>
>><br>
>> On 2 May 2014, at 09:16, David Tweed <<a href="mailto:david.tweed@arm.com" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=david.tweed@arm.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">david.tweed@arm.com</a>> wrote:<br>

>><br>
>>> I wonder if, with C++11 named initialization syntax for PODs, something<br>
>>> could be done so that in cases like this a (function specific, I guess)<br>
>>> "optional options object" could be used. (This would avoid one of the big<br>
>>> problems with C++ optional arguments, which is that if one towards the<br>
>>> end<br>
>>> needs to be set to a non-default value all the preceding options need<br>
>>> setting.) That would certainly make things a lot easier to read in cases<br>
>>> like these.<br>
>><br>
>> The related issue is that they complicate overloading.  I've been bitten a<br>
>> few times in clang code by the compiler deciding that, when I specified a<br>
>> pointer instead of a reference for a parameter, it would happily coerce it<br>
>> to a bool and then use the default values for the rest of the parameters,<br>
>> giving some very strange results - no errors, no warnings, just the code<br>
>> doing something unexpected.<br>
>><br>
>> David<br>
>><br>
> David, I think you're pointing out a slightly different issue... one I've<br>
> also been bitten by.<br>
><br>
> Does anyone know of a legitimate reason to have an implicit conversion to<br>
> bool as a function argument?  Maybe we should add an optional warning for<br>
> this case in particular?<br>
<br>
</div>My suspicion is that this would (just barely) not meet our bar for<br>
false positive rate. (my bet, though it's not a sure thing, is that we<br>
do this in the LLVM project at least tens of times intentionally (ie:<br>
not a bug, but subtle code))<br>
<br>
But, arguably, rewriting the argument from "func(x)" to "func(x !=<br>
nullptr)" is a benefit in readability and sometimes we're OK with a<br>
few more false positives if they're just "badly written/confusing<br>
code"<br></blockquote><div><br></div><div>I feel like this warning would be quite useful/valuable if it is (or can be) limited to implicit bool conversions for optional arguments.  Though like you, I suspect warning on implicit bool conversions even for required arguments may not fall under the threshold for false positives.</div>
<div><br></div><div>Cheers,</div><div>Kaelyn</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- David<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-commits@cs.uiuc.edu&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">cfe-commits@cs.uiuc.edu</a><br>

<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>