Static foreach bug?

[rikki cattermole]

On 05/09/2018 11:39 PM, Jonathan M Davis wrote:
> 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

Indeed. scope enum would make much more sense.