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


Reply via email to