[cfe-commits] r141768 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td lib/AST/DeclCXX.cpp lib/Sema/SemaType.cpp test/CXX/basic/basic.types/p10.cpp

[Douglas Gregor]

On Oct 12, 2011, at 11:07 AM, Richard Smith wrote:

> On Wed, October 12, 2011 17:09, Douglas Gregor wrote:
>> On Oct 11, 2011, at 10:08 PM, Richard Smith wrote:
>>> Author: rsmith
>>> Date: Wed Oct 12 00:08:15 2011
>>> New Revision: 141768
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=141768&view=rev
>>> Log:
>>> constexpr: don't consider class types with mutable members to be literal
>>> types.
>>> 
>>> The standard doesn't allow this, but mutable constexpr variables break the
>>> semantics so badly that we can't reasonably accept them.
>> 
>> Can you explain a bit? We can't assign to the mutable variables anyway.
> 
> Actually... the C++11 IS says this is legal:
> 
> struct MM {
>  mutable int n;
> }; // MM is a literal type
> 
> template<int n> struct Id { int k = n; };
> int f() {
>  constexpr MM m = { 0 }; // m is const, but...
>  ++m.n;                  // m.n is mutable
>  return Id<m.n>().k;     // an lvalue-to-rvalue conversion on any subobject
>                          // of a constexpr object is a constant expression
> }

Oh, my.

> There are two natural ways of fixing this: either (a) we say that an
> lvalue-to-rvalue conversion on a mutable subobject of a constexpr object is
> not a constant expression, or (b) we say that a class with a mutable member is
> not a literal type.
> 
> The various constexpr papers have made it clear that the constexpr specifier
> is supposed to mean (among other things) "this variable is ROM-able", so (b)
> seems like the right fix.

Ah, yes; I'd forgotten the heavy focus on ROM-ability. I agree that this is the right way to go.


>> And… have you submitted a core issue on this?
> 
> Not yet, I'll send an email to comp.std.c++ later today (unless there's a
> better way?).


I believe that will work.

	- Doug