On Wednesday, September 5, 2018 5:19:04 AM MDT Dechcaudron via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 10:45:20 UTC, Jonathan M Davis
>
> wrote:
> > Too many people already think that the point of static is to
> > just make something be done at compile time (which is actually
> > a pretty terrible reason to use static) without adding that
> > sort of thing into the confusion.
>
> Well, "static" in English means something that does not change
> (so do constant and immutable, but that's another story). One
> could argue that using static for function-scope variables with
> extended lifespan and for variables shared between instances of a
> class is more misleading. But since virtually every language out
> there uses them for that purpose, I understand we want to go with
> it. But then again, "static if" and "static foreach" make sense
> to me. And since all enums are compile time constants by
> definition, "static enum" may be a good way to tell them apart,
> although I do agree that it is far from ideal.
>
> I understand that the syntax for CT if and foreach blocks is not
> going to be changed for good reasons now, but was something like
> "CTif" considered at the time? I know it doesn't "look" good as
> is, but maybe some small variation could have done the trick.
The thing is that static already has a meaning when it's used on a variable
declaration.
static foo = 42;
and
enum foo = 42;
already have distinct meanings, and _everything_ having to do with enums is
already a compile-time thing. So, something like
static enum foo = 42;
really stands no chance of being anything other than highly confusing. Not
to mention, you then get into the fun question of what happens when someone
does something like
static
{
enum foo = 42;
}
or
static:
enum foo = 42;
And actually, right now,
static enum foo = 42;
has exactly the same meaning. In all three cases, the static is ignored,
because it's meaningless to apply it to an enum. So, making
static enum foo = 42;
change its meaning could actually break code (albeit code that's badly
written), and if
static enum foo = 42;
had a special meaning, then it would be inconsistent if the
static { enum foo = 42; }
or
static: enum foo = 42;
versions acted differently. And those actually are much more likely to break
otherwise valid code.
Conceptually, what Timon is talking about doing here is to add an attribute
to symbols declared within a static foreach where that attribute indicates
that the symbol is temporary (or at least scoped to a particular iteration
of the loop). So, saying that it's "local" as __local would makes perfect
sense. It's local to that iteration of the loop.
And there may very well be other syntaxes which would be better, but trying
to overload the meaning of static even further by using it in this context
would risk code breakage and would be _very_ confusing for most people.
- Jonathan M Davis
