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.

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

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.

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.

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.md#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.

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?

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

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

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

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.