www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Static foreach bug?

reply bauss <jj_1337 live.dk> writes:
Is there a reason why you cannot create a separate scope within a 
static foreach?

The below will not compile:

```
enum a = ["a" : "a", "b" : "b", "c" : "c"];

static foreach (k,v; a)
{
     {
         enum b = k;
         enum c = v;
     }
}
```

It works if it's in a function of course.

This creates a big limitation when you're trying to ex. loop 
through members of inherited classes, interfaces etc. and then 
want to store the information in variables, because you cannot do 
it. Which means to work around it you have to do it all in an 
ugly one-liner.

Is it intended behavior? If so, why? If not is there a workaround 
until it can be fixed?
Sep 02 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Sunday, 2 September 2018 at 13:21:05 UTC, bauss wrote:

 Is there a reason why you cannot create a separate scope within 
 a static foreach?


You can try it out here: https://run.dlang.io/is/7DgwCk
Sep 02 2018
prev sibling next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Sunday, 2 September 2018 at 13:21:05 UTC, bauss wrote:

 Is there a reason why you cannot create a separate scope within 
 a static foreach?

 The below will not compile:

 ```
 enum a = ["a" : "a", "b" : "b", "c" : "c"];

 static foreach (k,v; a)
 {
     {
         enum b = k;
         enum c = v;
     }
 }
 ```

 It works if it's in a function of course.

 This creates a big limitation when you're trying to ex. loop 
 through members of inherited classes, interfaces etc. and then 
 want to store the information in variables, because you cannot 
 do it. Which means to work around it you have to do it all in 
 an ugly one-liner.

 Is it intended behavior? If so, why? If not is there a 
 workaround until it can be fixed?


It's intended, but with the possibility to add special syntax for 
local declarations in the future left open, as per:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#local-declarations
Sep 02 2018
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 2 September 2018 at 13:26:55 UTC, Petar Kirov 
[ZombineDev] wrote:

 It's intended, but with the possibility to add special syntax 
 for local declarations in the future left open, as per:
 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#local-declarations


Is there any plans to implement it soon or is this going to be 
another half done feature?
Sep 02 2018
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02.09.2018 15:45, bauss wrote:

 On Sunday, 2 September 2018 at 13:26:55 UTC, Petar Kirov [ZombineDev] 
 wrote:

 It's intended, but with the possibility to add special syntax for 
 local declarations in the future left open, as per:
 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.m
#local-declarations 


 
 Is there any plans to implement it soon


It has been implemented for a long time (which you will find is actually 
clearly stated if you follow the link above). The only blocker is 
finding a good syntax. Currently, it would be:

static foreach(i;0..2){
     __local enum x = 2;
}


 or is this going to be another half done feature?


The feature is complete. There are just some further features that might 
go well with it.
Sep 04 2018
parent reply Dechcaudron <no-reply no-email.com> writes:
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?
Sep 05 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 5, 2018 4:29:32 AM MDT Dechcaudron via Digitalmars-d 
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?


Like it would be really, really confusing. 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. Timon's suggested __local is
infinitely better IMHO.

- Jonathan M Davis
Sep 05 2018
parent reply Dechcaudron <no-reply no-email.com> writes:
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.

Rgds,
Dechcaudron
Sep 05 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 05 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Sep 05 2018
parent reply Andre Pany <andre s-e-a-p.de> writes:
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
Sep 05 2018
next sibling parent reply JN <666total wp.pl> writes:
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.
Sep 05 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Sep 05 2018
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Sep 05 2018
prev sibling parent reply Dechcaudron <no-reply no-email.com> writes:
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
Sep 06 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 06 2018
parent Dechcaudron <no-reply no-email.com> writes:
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
Sep 07 2018
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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).
Sep 05 2018
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 2 September 2018 at 13:21:05 UTC, bauss wrote:

 Is there a reason why you cannot create a separate scope within 
 a static foreach?

 The below will not compile:

 ```
 enum a = ["a" : "a", "b" : "b", "c" : "c"];

 static foreach (k,v; a)
 {
     {
         enum b = k;
         enum c = v;
     }
 }
 ```

 It works if it's in a function of course.
 [...]


At the global scope it cant work since there even block 
statements are not possible, just this

```
{
     enum b = 0;
     enum c = 0;
}
```

doesn't compile; and this is what you tried to add in the `static 
foreach` body. So if i understand correctly this is even not a 
`static foreach` issue here.
Sep 02 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, September 2, 2018 7:21:05 AM MDT bauss via Digitalmars-d wrote:

 Is there a reason why you cannot create a separate scope within a
 static foreach?

 The below will not compile:

 ```
 enum a = ["a" : "a", "b" : "b", "c" : "c"];

 static foreach (k,v; a)
 {
      {
          enum b = k;
          enum c = v;
      }
 }
 ```

 It works if it's in a function of course.

 This creates a big limitation when you're trying to ex. loop
 through members of inherited classes, interfaces etc. and then
 want to store the information in variables, because you cannot do
 it. Which means to work around it you have to do it all in an
 ugly one-liner.

 Is it intended behavior? If so, why? If not is there a workaround
 until it can be fixed?


If you're not inside a function, why would it even be useful to be able to
do that? That would be the equivalent of

{
    enum b = "a";
    enum c = "a";
}
{
    enum b = "b";
    enum c = "b";
}
{
    enum b = "c";
    enum c = "c";
}

Creating scopes like that isn't legal outside of a function (hence the
compiler error), but even if it were, what good would it do you? There's no
way to refer to those scopes. The only way that such declarations would make
sense is if they're inside scopes with their own names so that they can be
referred to via those names (e.g. inside a struct or template) or if they
aren't in separate scopes and have unique names (which would mean giving
them names other than b and c rather than trying to scope them). I fail to
see why what you're complaining about here would even be useful.

Now, the fact that it's a bit of a pain to give each of those enums a unique
name can certainly be annoying, and that's a problem with static foreach in
general, but I don't understand why creating an extra scope like you're
trying to do here would be at all useful outside of a function. What are you
really trying to do here?

- Jonathan M Davis
Sep 02 2018
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 2 September 2018 at 18:07:10 UTC, Jonathan M Davis 
wrote:

 On Sunday, September 2, 2018 7:21:05 AM MDT bauss via 
 Digitalmars-d wrote:

 Is there a reason why you cannot create a separate scope 
 within a static foreach?

 The below will not compile:

 ```
 enum a = ["a" : "a", "b" : "b", "c" : "c"];

 static foreach (k,v; a)
 {
      {
          enum b = k;
          enum c = v;
      }
 }
 ```

 It works if it's in a function of course.

 This creates a big limitation when you're trying to ex. loop 
 through members of inherited classes, interfaces etc. and then 
 want to store the information in variables, because you cannot 
 do it. Which means to work around it you have to do it all in 
 an ugly one-liner.

 Is it intended behavior? If so, why? If not is there a 
 workaround until it can be fixed?


 If you're not inside a function, why would it even be useful to 
 be able to do that? That would be the equivalent of

 {
     enum b = "a";
     enum c = "a";
 }
 {
     enum b = "b";
     enum c = "b";
 }
 {
     enum b = "c";
     enum c = "c";
 }

 Creating scopes like that isn't legal outside of a function 
 (hence the compiler error), but even if it were, what good 
 would it do you? There's no way to refer to those scopes. The 
 only way that such declarations would make sense is if they're 
 inside scopes with their own names so that they can be referred 
 to via those names (e.g. inside a struct or template) or if 
 they aren't in separate scopes and have unique names (which 
 would mean giving them names other than b and c rather than 
 trying to scope them). I fail to see why what you're 
 complaining about here would even be useful.

 Now, the fact that it's a bit of a pain to give each of those 
 enums a unique name can certainly be annoying, and that's a 
 problem with static foreach in general, but I don't understand 
 why creating an extra scope like you're trying to do here would 
 be at all useful outside of a function. What are you really 
 trying to do here?

 - Jonathan M Davis


Let me demonstrate why it's useful with just this unmaintainable 
piece of code:

```
final class ClassName : SoapBinding, Interface
{
   public:
   final:
   this()
   {
     super();
   }
    import __stdtraits = std.traits;
    static foreach (member; __traits(derivedMembers, Interface))
   {
     mixin
     (
       mixin("(__stdtraits.ReturnType!" ~ member ~ ").stringof") ~
       " " ~
       member ~
       "(" ~
         mixin("parameters!" ~ member) ~
       ") { /* Do stuff ... */ }"
     );
   }
}
```

Woud be so much more maintainable if I could have each statement 
into a variable that could be maintained properly.
Sep 02 2018
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:

 Woud be so much more maintainable if I could have each 
 statement into a variable that could be maintained properly.


You could extract the body of the static foreach into a 
[template] function.
Sep 02 2018
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh wrote:

 On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:

 Woud be so much more maintainable if I could have each 
 statement into a variable that could be maintained properly.


 You could extract the body of the static foreach into a 
 [template] function.


I'm aware of that, but it's an unnecessary work around for 
something as trivial as the alternative would have been.
Sep 02 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote:

 On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh 
 wrote:

 On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:

 Woud be so much more maintainable if I could have each 
 statement into a variable that could be maintained properly.


 You could extract the body of the static foreach into a 
 [template] function.


 I'm aware of that, but it's an unnecessary work around for 
 something as trivial as the alternative would have been.


You would need to mark symbols as scoped to the static foreach 
body, or else as exported from a scope to an outer scope. So it's 
not exactly trivial.
Sep 02 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Monday, 3 September 2018 at 06:39:17 UTC, Neia Neutuladh wrote:

 On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote:

 On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh 
 wrote:

 On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:

 Woud be so much more maintainable if I could have each 
 statement into a variable that could be maintained properly.


 You could extract the body of the static foreach into a 
 [template] function.


 I'm aware of that, but it's an unnecessary work around for 
 something as trivial as the alternative would have been.


 You would need to mark symbols as scoped to the static foreach 
 body, or else as exported from a scope to an outer scope. So 
 it's not exactly trivial.


It's more trivial than having them in another part of the code.

I changed my implementation though to move away from static 
foreach for now and just generate a huge mixin from the 
definitions of the generated interface.
Sep 02 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
n Monday, September 3, 2018 12:39:17 AM MDT Neia Neutuladh via Digitalmars-d 
wrote:

 On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote:

 On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh

 wrote:

 On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:

 Woud be so much more maintainable if I could have each
 statement into a variable that could be maintained properly.


 You could extract the body of the static foreach into a
 [template] function.


 I'm aware of that, but it's an unnecessary work around for
 something as trivial as the alternative would have been.


 You would need to mark symbols as scoped to the static foreach
 body, or else as exported from a scope to an outer scope. So it's
 not exactly trivial.


Yeah. Having scoping wouldn't work. You would either need a way to name each
of the enums individually (which you can totally do - it's just a bit of a
pain), or you'd need a way to indicate that a particular enum was somehow
scoped to that particular iteration of the loop while the symbol you really
wanted was not restricted to that iteration.

Really, what this comes down to is that static foreach doesn't do anything
special beyond extend what foreach already did when iterating over a
compile-time construct like an AliasSeq. It makes it so that you can iterate
over stuff like arrays at compile-time (instead of just stuff that only
exists at compile-time), and it makes it so that you can use it outside of
functions in order to add declarations, but it works fundamentally the same
way. The only major difference in its semantics is that it does not
introduce a new scope (unlike a foreach over an AliasSeq), because that
doesn't work with declarations, but otherwise, it works basically the same
as a foreach of an AliasSeq. You would need a fundamentally new construct in
order to have something that's somehow tied to a particular iteration of the
loop while still having having declarations that aren't tied to a particular
iteration of the loop. While such a construct would be useful for some uses
of static foreach, it wasn't part of the core concept, and it's far less
obvious what such a construct should look like. Maybe, we'll get such an
improvement at some point, but it's not necessariy for static foreach to do
its core job.

As things stand, if you want to create a symbol specific to a particular
iteration of the loop, you're going to have to use a string mixin to give it
a name unique to that iteration (presumably embedding either the index or
the key into the name).

- Jonathan M Davis
Sep 03 2018
prev sibling parent reply Soma <soma gmail.com> writes:
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:

 unmaintainable piece of code:

 ```
 final class ClassName : SoapBinding, Interface
 {
   public:
   final:
   this()
   {
     super();
   }
    import __stdtraits = std.traits;
    static foreach (member; __traits(derivedMembers, Interface))
   {
     mixin
     (
       mixin("(__stdtraits.ReturnType!" ~ member ~ ").stringof") 
 ~
       " " ~
       member ~
       "(" ~
         mixin("parameters!" ~ member) ~
       ") { /* Do stuff ... */ }"
     );
   }
 }
 ```


Sorry to disrupt your threat, but as a lurking in this forum 
using D for small projects, and after looking such snippet my 
first impression is how D is getting polluted and becoming more 
like Java and C++.

"final class", "public final this", "super"...

And of course this is just the beginning, other attributes:

"inout", " disable", " system".

And keeps funny when names are somewhat 'synonymous': "shared", 
"__gshared"

or like these 3: " safe", " trusted", "pure"

or like these 2: "const", "immutable".

And the list goes on and on...

For beginners (Or even average programmers) it would be "very 
nice" to not confuse them.

Soma.
Sep 03 2018
parent Meta <jared771 gmail.com> writes:
On Monday, 3 September 2018 at 18:03:18 UTC, Soma wrote:

 Sorry to disrupt your threat, but as a lurking in this forum 
 using D for small projects, and after looking such snippet my 
 first impression is how D is getting polluted and becoming more 
 like Java and C++.

 "final class", "public final this", "super"...


I agree with you that D has more than a few function attributes 
and it gets confusing, but I'd like to point out that "final", 
"public", "super", etc. have been in D since the first version of 
D1, if I'm not mistaken.
Sep 03 2018