Confusion/trying to understand CTFE keywords

[Jonathan M Davis]

On Monday, June 04, 2018 14:05:28 gdelazzari via Digitalmars-d-learn wrote:
> On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
> > So, while static _seems_ somewhat inconsistent at first, the
> > way it's used is pretty consistent overall. The main
> > inconsistency is the places where static is essentially
> > implicit rather than explicit (such as module-level variables
> > or structs nested in other structs or classes).
>
> I'm not getting this however. I mean, sure, it's totally
> consistent if you consider the cases you described, but what I
> meant is that in a piece of code like
>
> static if (a == 3)
> {
>    // stuff...
> }
> static else if (a == 2)
> {
>    // other stuff...
> }
> else
> {
>    // etc...
> }
>
> the "static" keyword has a different meaning, in this case it
> means that the if gets evaluated at compile time. This is the
> kind of inconsistency I was talking about.

Yeah, that would be inconsistent with the others. I'd forgotten about those
when I wrote my reply. Basically, in the case of static if, static foreach,
and static assert, it just means that it's the compile-time variant of the
construct in question. The keyword reuse works well, but it is inconsistent
with the other uses. I guess that it could be argued that they don't have a
context, because they're done at compile-time, whereas the runtime variants
are run within a specific context, but I think that that's stretching
things. However, static used with static if, static foreach, and static
assert seems to be very easy for people to understand, whereas some of the
other ways it's used often cause confusion at first. Certainly, it seems to
be far less confusing for folks than using enum for manifest constants has
been.

> Of course "static if" doesn't sound bad at all, it somehow
> conveys the idea of what it actually does. My confusion was
> regarding the fact that "static" is also used for other things
> (the ones you described) and then I would also expect that, to
> define a compile-time value, I would use the same keyword again,
> like
>
> static myCompileTimeValue = 5 * 2;
>
> instead of
>
> enum myCompileTimeValue = 5 * 2;
>
> of course this wouldn't be possible with the keyword "static",
> since `static val = 4;` would have a totally different meaning in
> the language, and that's why "enum" is used I guess. But then why
> not `enum if (...) { ... }`? Again, forget about the keywords
> themselves, I'm just talking about using the same one which is
> different from keywords that also do other different (or
> completely different, or slightly different, but still different)
> things. I get that "enum" has somewhat of a sense, when doing
> `enum val = 4;`, after reading the related book chapter, but
> yeah... that's not the problem, as I hope you now understood what
> I mean.

Using enum instead of static in contexts such as static if would be using
enum in a drastically different context from where enum is normally used
(the issue of manifest constants already causes a fair bit of confusion),
whereas static seems fairly natural there, and folks are used to static
meaning multiple things. In both C/C++ and D, static gets used in multiple
contexts where most folks would think that they were completely different
when in fact it's possible to come up with a definition that covers most or
all of the contexts in which it's used. So, regardless of whether static is
actually used consistently, it doesn't feel consistent. So, reusing it for
static if is likely to seem much more reasonable to many folks, whereas I
think that relatively few would think that reusing enum for that would have
made sense. But language design is a bit of an art. It's an interesting
combination of doing what makes sense from the standpoint of the compiler
writer and what makes sense from the standpoint of the programmer using the
language.

> This argument I started was kind of a first-impression as a
> newcomer to the language, with the hope of getting to better
> understand it. Also I thought it's beneficial for the community
> to have feedback from new users.

Constructive feedback is always welcome. And even if nothing in the language
gets changed because of feedback, it does help us understand where people
need help learning the language.

- Jonathan M Davis