September 05, 2018
On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote:

> Indeed. scope enum would make much more sense.

scope enum sounds a lot better for me than static enum or even __local. The __ words looks a little bit like compiler magic as the __ words are reserved for the compiler.

Kind regards
Andre
September 05, 2018
On Wednesday, 5 September 2018 at 12:41:05 UTC, Andre Pany wrote:
> On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote:
>
>> Indeed. scope enum would make much more sense.
>
> scope enum sounds a lot better for me than static enum or even __local. The __ words looks a little bit like compiler magic as the __ words are reserved for the compiler.
>
> Kind regards
> Andre

To be honest, using enum as "compile-time variable" is magic enough. Enum should be reserved for enumerations. But I guess it's one of those things that is too late to change.
September 06, 2018
On 06/09/2018 12:52 AM, JN wrote:
> On Wednesday, 5 September 2018 at 12:41:05 UTC, Andre Pany wrote:
>> On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote:
>>
>>> Indeed. scope enum would make much more sense.
>>
>> scope enum sounds a lot better for me than static enum or even __local. The __ words looks a little bit like compiler magic as the __ words are reserved for the compiler.
>>
>> Kind regards
>> Andre
> 
> To be honest, using enum as "compile-time variable" is magic enough. Enum should be reserved for enumerations. But I guess it's one of those things that is too late to change.

An enum is some sort of constant. As long as something like scope enum remains a constant and not an actual variable that can be modified, then I think that it is ok naming-wise.

Of course the manifest enum's that you're referring to is a remnant of #define in C. So it sort of makes sense and a little not at the same time. Tis' weird.
September 05, 2018
On 05.09.2018 14:41, Andre Pany wrote:
> On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote:
> 
>> Indeed. scope enum would make much more sense.
> 
> scope enum sounds a lot better for me than static enum or even __local. The __ words looks a little bit like compiler magic as the __ words are reserved for the compiler.
> 
> Kind regards
> Andre

I agree, but it is not an option as scope already has a different meaning, and so this would redefine the semantics of existing code.
September 05, 2018
On 05.09.2018 12:29, Dechcaudron wrote:
> On Tuesday, 4 September 2018 at 19:50:27 UTC, Timon Gehr wrote:
>> The only blocker is finding a good syntax.
> 
> How does "static enum" sound?

It can't be anything that is legal code today (__local works for all declarations, not just enums).
September 06, 2018
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.

Rgds,
Dechcaudron
September 06, 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



September 07, 2018
On Thursday, 6 September 2018 at 15:56:50 UTC, Jonathan M Davis wrote:
> 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.

I don't see any reason why @gshared/@ctlocal (with or without '@')could not be restricted to variables, just like @nogc is restricted to functions.

Regards,
Dechcaudron


1 2 3
Next ›   Last »