Re: static const double pi = 3.1415;

[kaih at khms dot westfalen dot de (Kai Henningsen)]

gdr at integrable-solutions dot net (Gabriel Dos Reis)  wrote on 19.02.03 in <m3d6lo904k dot fsf at uniton dot integrable-solutions dot net>:

> kaih at khms dot westfalen dot de (Kai Henningsen) writes:
>
> | Note I'm not arguing for or against any particular extension here.
> |
> | That said - what would be hard about allowing to initialize PODs with
> | constant expressions?
>
> I don't know how hard it would be.  But I do know for sure that a
> couple of bugs on that issue have made their ways into the compiler.
> Getting rid of that undocumented extension certainly makes the job of
> implementing the language easier.
>
> Now, if you want that feature,

Note my first sentence above.

> maybe you might come with a detailled
> specification -- no, the undocumented extension didn't describe the
> semantics.
>
> what is clear is that integral constant and enumeration are considered
> compile-time entities and as such maybe "optimized" away by the
> compiler -- that is the main prupose of the standard feature.
> However, the picture is less clear when you consider non-compile time
> entities.

Frankly, that answer doesn't make sense to me.

Let me try to put the question differently.

Exhibit 1:

static sometype = someexpression;

Exhibit 2:

class foo {

static sometype = someexpression;

[...]
};

What is the justification for putting stronger requirements on the Exhibit  
2 case than on the Exhibit 1 case? (That is, why does the standard make a  
difference here?)

That is what is unobvious.

As for a detailed specification: "Handle Exhibit 2 exactly like Exhibit 1,  
except for namespace issues." That would certainly follow the principle of  
least surprise. What is hard about that?

I can't decide to prefer one version over the other until I know why there  
is a difference in the first place. Maybe there is a good reason - but  
until now, I haven't seen any argument that doesn't seem to be restricted  
to "the standard says so". Well duh, we already know that. It doesn't  
answer the question - it *causes* the question.

MfG Kai