Static foreach bug?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Sep 6 15:56:50 UTC 2018


On Thursday, September 6, 2018 3:11:14 AM MDT Dechcaudron via Digitalmars-d 
wrote:
> On Wednesday, 5 September 2018 at 11:39:31 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> You are right, using "static" would be confusing I guess. I'm
> just against starting to use __keywords reserved to the compiler
> that maybe shouldn't be. I know we already have __gshared,
> though. Just what is the criteria to prepend the double
> underscore to a keyword? Why now just use an @attribute instead?
> @gshared and @ctlocal would fit better in the D style, IMO.

__ can be used for any identifier that is reserved by the compiler. There
have been identifiers which start with __ since the language began, whereas
attributes are a later edition to the language. And regardless of whether
@gshared would make sense, __gshared predates attributes, so there's no way
that it would be @gshared. However, since attributes are applied to
functions, and __gshared is for variables, it really wouldn't make sense to
have @gshared, and by that same token, it wouldn't make sense to have
@ctlocal.

- Jonathan M Davis





More information about the Digitalmars-d mailing list