r187735 - Implement C++'s restrictions on the type of an expression passed to a vararg

[John McCall]

On Aug 5, 2013, at 1:42 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Mon, Aug 5, 2013 at 1:19 PM, John McCall <rjmccall at apple.com> wrote:
> On Aug 5, 2013, at 11:49 AM, Richard Smith <richard-llvm at metafoo.co.uk> wrote:
>> Author: rsmith
>> Date: Mon Aug  5 13:49:43 2013
>> New Revision: 187735
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=187735&view=rev
>> Log:
>> Implement C++'s restrictions on the type of an expression passed to a vararg
>> function: it can't be 'void' and it can't be an initializer list. We give a
>> hard error for these rather than treating them as undefined behavior (we can
>> and probably should do the same for non-POD types in C++11, but as of this
>> change we don't).
> 
> Doesn’t this change SFINAE behavior? 
> 
> I'm not sure whether your "this" binds to the change or to the parenthetical in the comment.
> 
> For the former, yes, and it's supposed to: 5.2.2/7 says the program is ill-formed.
> 
> For the latter, this is "conditionally-supported with implementation-defined semantics". Per 1.4/2, this means "when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message", and the intent is that implementations treat such constructs as being ill-formed if they do not support them. Our current implementation is conforming, if unfriendly. FWIW, g++ rejects such constructs.

Are you sure it doesn’t just reject them if potentially evaluated?  Overloads where one option is (...) are pretty much standard.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130805/d3be8f96/attachment.html>