[cfe-dev] error: initialized if it is a static const integral data member

[Douglas Gregor]

On Feb 19, 2010, at 8:41 AM, Rene Rebe wrote:

> 
> On 19.02.2010, at 17:34, Douglas Gregor wrote:
> 
>> On Feb 19, 2010, at 7:50 AM, Rene Rebe wrote:
>> 
>>> Hi all,
>>> 
>>> still getting some production code to compile the next error is:
>>> 
>>> test.cc:5:26: error: in-class initializer has non-integral, non-enumeration type 'double'
>>> 
>>> While the type is a double in this case. This is tested in the clang testsuite:
>>> 
>>> test/SemaTemplate/instantiate-static-var.cpp
>>> 
>>> template<typename T>
>>> class Y {
>>> static const T value = 0; // expected-error{{'value' can only be initialized if it is a static const integral data member}}
>>> };
>>> 
>>> Y<float> fy; // expected-note{{in instantiation of template class 'class Y<float>' requested here}}
>>> 
>>> G++ (even 4.4) does not even warn about this on neither -Wall, nor -Wextra, only with -pedantic. I assume due to this other POD initialization, especially of FP types will occur in quite some shipping code and thus suggest making it a warning, likewise.
>> 
>> 
>> Or they are treating it like an out-of-class initializer. It's hard to tell.
>> 
>> But the code is clearly wrong, and Clang is right to diagnose it.
> 
> 
> I did not mean to remove the diagnostic, but make it a warning.

If we do that, we'll end up breaking an invariant of the C++ abstract syntax tree, which is that we only have in-class initializers of integral or enumeration type. That has ramifications on other parts of the compiler, which need to be understood. 

> Personally I find those arbitrary and artificial C++ limitations just annoying. We certainly can not expect the world's source code to be rewritten to match clang's liking when other compiler accept the code.

It's not "Clang's liking", it's an ISO standard. Clang aims to be a highly-conformant C++ compiler, and that means following the letter of the standard. We make some concessions to compatibility, but a problem typically has to occur in a lot of code or be extremely hard to work around before we'll consider such a change.

	- Doug