Confusion/trying to understand CTFE keywords

[gdelazzari]

On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
>
> I think that part of your problem here comes from the fact that 
> you think of enum or static are "CTFE keywords." That's not 
> what they are at all. Yes, they can trigger CTFE, but they're 
> not the only way.
>
> ...

Thank you very much for the extensive explanation, I really 
appreciate it. I'm slowly getting the point here, also by reading 
the relevant parts of the book you linked.

I was aware of the meaning of the static keyword (coming from 
other languages where it has similar meaning), but your re-cap 
was great anyway since I now have a clear view of how exactly 
works in D with the various features of the language.

> 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.

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.

> If you haven't yet, I'd suggest reading
>
> http://ddili.org/ders/d.en/index.html
>
> Even if you understand most of the content already, it will 
> probably help fill in some of the holes you have in your 
> understanding, and depending on how much you've done with D, it 
> may contain quite a bit of new content that will help you out.
>
> - Jonathan M Davis

Again, thank you very much for the time you took to answer with 
that amount of quality information, I really appreciate it. And I 
also appreciate the suggestion about the book, which I'll read as 
soon as I can. Maybe I'm missing somewhat of a broader view of 
the language that, once acquired, will make me understand the 
real meanings/reasons behind those keywords.

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.

Thank you very much again,
Giacomo