On Tuesday, June 05, 2018 22:08:32 Stefan Koch via Digitalmars-d-learn wrote: > On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer > > wrote: > > No, it's definitely a bug. main is not being evaluated at > > compile time. The real result of this function should be a > > compile-time error -- __ctfe is a *runtime* value that is > > always defined based on whether you are __ctfe or not. > > Therefore, n must be a runtime value, and not usable as a > > static array dimension. > > > > If the posted code is valid, then this should be valid as well: > > > > static if(__ctfe) > > > > immutable n = 1; > > > > else > > > > immutable n = 2; > > > > But it's not. > > > > -Steve > > I see what you mean. > I fear fixing this bug will not be easy without breaking arguably > valid uses.
Any such case should work by either using an enum instead or using an enum to have the value during CTFE and then initialize a const or immutable variable with it. We'd likely need to deprecate the old behavior rather than simply fixing it in order to avoid breaking code, but the result would ultimately be cleaner, and it should be easy for any affected code to be updated. As is standsw the fact that immutable i = foo(); int[i] arr; works and uses CTFE whereas immutable i = foo(); doesn't do any CTFE just increases the confusion of how CTFE works. The fact that __ctfe then affects things further just makes matters worse. CTFE really should only kick in when it has to kick in. That way, it's clean and understandable as to when it kicks in and when it doesn't, and anyone who wants to initialize a local variable with CTFE can always just use an intermediary enum. We have too much confusion over when CTFE kicks in even without this quirk with immutable. - Jonathan M Davis
