[cfe-commits] r149286 - in /cfe/trunk: lib/AST/ExprConstant.cpp lib/Sema/SemaOverload.cpp test/CXX/expr/expr.const/p2-0x.cpp

[Abramo Bagnara]

Il 03/02/2012 02:46, John McCall ha scritto:
> On Feb 2, 2012, at 2:41 PM, Abramo Bagnara wrote:
>> Il 02/02/2012 23:27, Richard Smith ha scritto:
>>>
>>>
>>> Yes, absolutely. As in my original example:
>>>
>>>   enum E { n = 2 };
>>>   E e = (E)5;
>>>
>>> Here, I think that (E)5 is not a constant expression, but (E)3 is.
>>> Possibly we're in violent agreement about that?
>>
>> My reading of the standard confirms that: the value of (E)5 is defined
>> "unspecified" and there is no warranty that (int)(E)5 is equal to 5.
> 
> If the value is merely unspecified, then it's still a constant expression
> under the DR1313 wording.

Yes, I understand and the standard supports that in 1.3.25:

unspecified behavior
behavior, for a well-formed program construct and correct data, that
depends on the implementation
[ Note: The implementation is not required to document which behavior
occurs. The range of possible
behaviors is usually delineated by this International Standard. —end note ]

However I strongly believe that accepting code like the following:

enum E { n = 2 };

template <E A>
int f() {
  return A;
}

int g() {
  return f<(E)5>();
}

without to give any info to the programmer about what is its behavior is
a mistake.

I think that we should improve that with one or more of the following:

1) decide what is the behavior we want to implement

2) "promote" the case to an implementation defined behavior (and then
documenting what programmer using clang can expect)

3) emit a warning for constant evaluation of this kind