<div dir="ltr"><div>The comma operator is rather useful for RAII objects and to disambiguate the vexing parse in favour of the expression.<br></div><div><br>For example (note: Clang does not handle this correctly; PR on the way):<br><span style="font-family:monospace,monospace">struct ContextRAII {<br>   ContextRAII(int);<br>};<br><br>int x[100];<br><br>void bar();<br><br>void foo(int idx) {<br>   ContextRAII(x[0, idx]), bar();<br>}</span><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 6:04 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.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="HOEnZb"><div class="h5"><br>
> On 2016-May-31, at 14:46, Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
><br>
> On Tue, May 31, 2016 at 5:28 PM, James Grosbach via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> On May 26, 2016, at 4:55 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
>><br>
>>><br>
>>> On 2016-May-26, at 16:16, Akira Hatanaka <<a href="mailto:ahatanak@gmail.com">ahatanak@gmail.com</a>> wrote:<br>
>>><br>
>>> On Thu, May 26, 2016 at 3:58 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
>>><br>
>>>> On 2016-May-25, at 16:41, Hal Finkel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> From: "James Dennett via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
>>>> To: "Akira Hatanaka" <<a href="mailto:ahatanak@gmail.com">ahatanak@gmail.com</a>><br>
>>>> Cc: "Richard Smith" <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>, "Clang Dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
>>>> Sent: Wednesday, May 25, 2016 6:37:46 PM<br>
>>>> Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?<br>
>>>><br>
>>>> On Wed, May 25, 2016 at 4:19 PM, Akira Hatanaka <<a href="mailto:ahatanak@gmail.com">ahatanak@gmail.com</a>> wrote:<br>
>>>> On Tue, May 24, 2016 at 7:11 PM, James Dennett <<a href="mailto:james.dennett@gmail.com">james.dennett@gmail.com</a>> wrote:<br>
>>>> On Tue, May 24, 2016 at 6:25 PM, Akira Hatanaka via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>> I wasn't requesting that clang accept lambda expressions used for array bounds but was asking whether it was valid in c++. Is this something that is open to interpretation because it's not covered by the standard?<br>
>>>><br>
>>>> FYI, this isn't something that I made up. It was in a code a user wrote.<br>
>>>><br>
>>>><br>
>>>> It's covered by the standard, and as Clang's error message says, lambdas are not allowed in constant expressions in C++11 or C++14.<br>
>>>><br>
>>>><br>
>>>> Yes, the c++ standard gives a list of subexpressions that are not allowed in constant expressions and lambda expression is one of them.<br>
>>>><br>
>>>> This doesn't seem to apply to C99's extension for variable length arrays because array sizes are not required to be constant expressions.<br>
>>>><br>
>>>><br>
>>>> I was replying to you saying that you were "asking whether it was valid in C++", and whether "it's not covered by the standard".<br>
>>>><br>
>>>> C99 doesn't have lambdas, so it doesn't allow this.  C++ doesn't have VLAs, so it doesn't allow it.<br>
>>>><br>
>>>> The de facto language accepted by Clang doesn't accept it, as you already noted.<br>
>>>><br>
>>>> There's no specification that tells us what the "right thing to do" is here.  We could extend Clang to support this non-standard combination of C99 with C++11, and it might even make it a little more consistent, but if it adds any implementation complexity then it may not be worthwhile to support a corner case that's not allowed by any language standard.<br>
>>>> What did the most recent wording for C++ ARBs say about this issue?<br>
>>><br>
>>> The latest version I could find is here:<br>
>>> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#Introduction" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#Introduction</a><br>
>>><br>
>>> The changes to 8.3.4 Arrays [dcl.array] change the argument from a constant-expression_opt to an expression_opt:<br>
>>> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#dcl.array" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#dcl.array</a><br>
>>><br>
>>> I think the Array TS was killed in Jacksonville due to lack of interest, but the interaction between these features seems straightforward to me.  When the C++ language extension for VLAs is turned on, we shouldn't treat the array argument as a constant-expression.  This effectively allows lambdas in array bounds.<br>
>>><br>
>>> Akira, what does the patch for this look like?<br>
>>><br>
>>><br>
>>> My first patch just replaced the call to ParseConstantExpresssion at ParseDecl.cpp:6106 with ParseExpression. I didn't see the error message about lambda after applying the patch. It also caused clang to accept expressions like this, if I remember correctly:<br>
>>><br>
>>> char a[1,2];<br>
>><br>
>> Hmm.  That would merit a warning.  IMO, -Wcomma should fire on every<br>
>> use of the built-in comma operator that's not in the "increment"<br>
>> statement of a for loop... I'm not sure if others agree though.<br>
>><br>
><br>
> I’m curious what that would look like on a large codebase. It sounds good to me, but potentially very noisy and perhaps a step too far in the direction of style enforcement rather than bug finding.<br>
> As it is, I find -Wlogical-op-parentheses and -Wmismatched-tags to be too noisy already.<br>
<br>
</div></div>I agree that -Wlogical-op-parentheses is fairly noisy, but IMO this<br>
would generate a *lower* amount of noise.  I think very few people<br>
actually use `,`, whereas `&&` and `||` are frequently used.<br>
<div class="HOEnZb"><div class="h5"><br>
> A case I’d like to make sure gets caught is:<br>
><br>
> int foo();<br>
> int bar();<br>
> ...<br>
> a = foo(), (void)bar();<br>
><br>
> There’s no warning or error for this code. However, change the assignment to a “return” and it’s a hard error. Precedence is a pain.<br>
><br>
> The real issue is the far more nefarious:<br>
> a = foo(), bar();<br>
><br>
> It’s going to be pretty darn rare to see that and the actual results being what was intended by the author.<br>
><br>
><br>
>><br>
>><br>
>>>><br>
>>>> -Hal<br>
>>>><br>
>>>> -- James<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> cfe-dev mailing list<br>
>>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Hal Finkel<br>
>>>> Assistant Computational Scientist<br>
>>>> Leadership Computing Facility<br>
>>>> Argonne National Laboratory<br>
>>>> _______________________________________________<br>
>>>> cfe-dev mailing list<br>
>>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
</div></div></blockquote></div><br></div>