https://issues.dlang.org/show_bug.cgi?id=17351
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from [email protected] --- (In reply to Andrei Alexandrescu from comment #3) > bool fun(const int a) { return true; } > bool gun(const int[3] a) { return true; } > > void main() > { > static const int x1 = 1; > static assert(fun(x1)); > static const int[3] x; > static assert(gun(x)); > } > > The int goes through, the int[3] does not although the pass by value > protocol is the same for both. You have to initialize the int[3], as you did with the int. I suppose the compiler assumes that you're going to do run-time initialization via `static this` when you're not initializing in the declaration. In that case, the value can't be used at compile time, obviously. [...] > bool fun(const int a) { return true; } > bool fun(ref const int a) { return true; } > > void main() > { > static const int x1 = 1; > static assert(fun(x1)); > } > > Here, the code attempts to avoid the problem by overloading on ref. However, > the call is resolved to the ref version even though it does not go through. > This should definitely be fixed, otherwise we're in the position of making a > workaround impossible. You can work around by using an enum instead of a static const. That makes x1 an rvalue, and the ref overload isn't involved anymore. It might be worthwhile to require enums for compile-time constants; i.e., ban non-enum consts/immutables. The const/immutable qualifiers simply don't imply compile-time constancy. enum does. That would be a breaking change, of course. And it would break benign code such as `static const a = 1; static const b = a + 1;`. But a clean cut may be better than confusing special cases. --
