On Mon, Aug 5, 2013 at 1:47 PM, John McCall <[email protected]> wrote:
> On Aug 5, 2013, at 1:42 PM, Richard Smith <[email protected]> wrote: > > On Mon, Aug 5, 2013 at 1:19 PM, John McCall <[email protected]> wrote: > >> On Aug 5, 2013, at 11:49 AM, Richard Smith <[email protected]> >> 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. > Yes, indeed it does. Somewhat amusingly, it has the same behavior for passing {} through an ellipsis, but gives an error for passing 'void' through an ellipsis even in an unevaluated context.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
