Confusion/trying to understand CTFE keywords

[Jonathan M Davis]

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