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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
