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