On Monday, 8 June 2015 at 22:12:06 UTC, Idan Arye wrote:
> On Monday, 8 June 2015 at 21:32:52 UTC, Timon Gehr wrote:
>> I think the body should have access to a scope that is hidden from the outside which contains the loop variable, but declarations should be inserted into the enclosing scope like for static if.
>
> This would require some syntax to mark the declarations we want to expose. Maybe `out`?
>
> This is far better than the mixin template approach, since it'll alert us early about conflicts:
>
>     static foreach (ident; ["a", "b", "a"])
>     {
>         int mixin(ident ~ "1");
>         out int mixin(ident ~ "2");
>     }
>
> `a1` is created twice, but that's OK since it isn't marked with `out`. `a2` is declared twice and raises a compilation error because it's marked with `out`. This will ensure these kind of errors are detected early and the compilation error points to the exact place of declaration.

I think it would make more sense to behave similar to how static if currently does.

On 06/09/2015 12:36 AM, Tofu Ninja wrote:
> On Monday, 8 June 2015 at 22:12:06 UTC, Idan Arye wrote:
>> On Monday, 8 June 2015 at 21:32:52 UTC, Timon Gehr wrote:
>>> I think the body should have access to a scope that is hidden from
>>> the outside which contains the loop variable, but declarations should
>>> be inserted into the enclosing scope like for static if.
>>
>> This would require some syntax to mark the declarations we want to
>> expose. Maybe `out`?
>>
>> This is far better than the mixin template approach, since it'll alert
>> us early about conflicts:
>>
>>     static foreach (ident; ["a", "b", "a"])
>>     {
>>         int mixin(ident ~ "1");
>>         out int mixin(ident ~ "2");
>>     }
>>
>> `a1` is created twice, but that's OK since it isn't marked with `out`.
>> `a2` is declared twice and raises a compilation error because it's
>> marked with `out`. This will ensure these kind of errors are detected
>> early and the compilation error points to the exact place of declaration.
>
> I think it would make more sense to behave similar to how static if
> currently does.

No, static if should be fixed, and then it should behave similarly to the fixed version:

void main(){
    static if(is(int T==int)){}
    T x; // wtf?
}

On 06/08/15 22:02, Andrei Alexandrescu via Digitalmars-d wrote:
> Walter and I are looking at ways to implement it. Here's a baseline without static foreach - a "trace" function that prints function calls before they are made:
> 
> http://dpaste.dzfl.pl/762c83c7fe30
> 
> If the function is overloaded, that won't work. In such cases, static foreach might be helpful. Here's code from the cycle "I have a dream":
> 
> http://dpaste.dzfl.pl/82a70c809210

The goal should be more like:

   template trace(alias fun) {
      static foreach (O; Overloads!fun)
         auto ref trace(Parameters!O args) {
              write("Tracing: ", __traits(identifier, fun), "(");
              foreach (i, arg; args) {
                  if (i) write(", ");
                  write(arg);
              }
              writeln(")");
              return fun(args);
         }
   }

And, btw, one of your asserts in that dreamy example has an off-by-one bug. Of course the only reason I spotted it is because I actually ran the code. ;) [1]

artur

[1] My old static-foreach hack makes it look like this:

  template trace(alias fun) {
      alias OS = Overloads!fun;
      #foreach (I, _; OS) {
         auto ref trace(Parameters!(OS[$I]) args) {
              write("Tracing: ", __traits(identifier, fun), "(");
              foreach (i, arg; args) {
                  if (i) write(", ");
                  write(arg);
              }
              writeln(")");
              return fun(args);
         }
      }
   }

which obviously isn't that pretty, but has the advantage of working right
now. But w/o a built-in implementation it (a) is a bit too verbose, and
(b) doesn't nest very well; a built-in version wouldn't have these problems.

On Monday, 8 June 2015 at 22:16:50 UTC, Timon Gehr wrote:
> On 06/09/2015 12:12 AM, Idan Arye wrote:
>> On Monday, 8 June 2015 at 21:32:52 UTC, Timon Gehr wrote:
>>> I think the body should have access to a scope that is hidden from the
>>> outside which contains the loop variable, but declarations should be
>>> inserted into the enclosing scope like for static if.
>>
>> This would require some syntax to mark the declarations we want to
>> expose. Maybe `out`?
>>
>> This is far better than the mixin template approach, since it'll alert
>> us early about conflicts:
>>
>>     static foreach (ident; ["a", "b", "a"])
>>     {
>>         int mixin(ident ~ "1");
>>         out int mixin(ident ~ "2");
>>     }
>>
>> `a1` is created twice, but that's OK since it isn't marked with `out`.
>> `a2` is declared twice and raises a compilation error because it's
>> marked with `out`. This will ensure these kind of errors are detected
>> early and the compilation error points to the exact place of declaration.
>
> I actually intended all declarations in the body to be inserted into the enclosing scope, at least by default.

What about helper declarations that repeat in each static iteration? It can work like with mixin templates, where declarations hide each other(http://dpaste.dzfl.pl/c173395eb0cd), but that means that if there is a repeat in the declaration you do want to expose, the compiler will simply hide it without issuing an error. You will get an error when you try to access that declaration from somewhere else, but this error message is distant from the root cause both in time - you might only write the code that access the declaration created by that particular iteration much later in the development process - and space - the error will point to the point of usage, not the point of duplicate declaration. Also, if the point of usage is inside a template and depends on the template instantiation this kind of error is much harder to debug...

As for exposing the declaration by default - unless there is a backward compatibility issue, it's usually best to make the most restrictive and contained version the default one. If not exposing is the default and someone neglects to mark the exposed declaration, it will fail immediately when they try to access it(and they will. Immediately. Because that's the code they are writing right now) and they can just add the annotation. But if exposing is the default, and someone neglects to mark the internal helpers as non-exposed, well - they better hope that there are duplications that'll expose their mistake. This is not always trivial:

    struct Foo(Types...)
    {
        static foreach (Type; Types)
        {
            static if (isSomeString!Type)
            {
                // I forgot to mark this as non-exposed
                void stringHelper()
                {
                    // helper for strings
                }

                void doSomething(Type arg)
                {
                    // Something that uses stringHelper
                }
            }
            else
            {
                void doSomething(Type arg)
                {
                    // The non-string versio
                }
            }
        }
    }

    unittest
    {
        alias MyFoo = Foo!(int, float, string);
        // some tests with MyFoo
    }

Since I only have one string in MyFoo's types list, `stringHelper` is only declared once. A month from now, when I try to create `Foo!(string, wstring)`, it'll create two `stringHelper`s and result in compilation error. Having an error show up a month later is not fun. It's much less fun when it it pops for someone else that now needs to figure out what you were trying to do...

That's why I think not exposing should be the default. In that case, since `doSomething` is not marked as exposed, this will fail early, because we can safely assume the exposed functionality is being tested - even if I don't write a proper unit test, since `doSomething` is part of `Foo`'s API I will try to use it(if you write API without at least trying it out you deserve whatever method of torture the people that use that API can think of), so the bug will pop early.

On Monday, 8 June 2015 at 22:15:32 UTC, rsw0x wrote:
> On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
>> I'm trying to collect together motivating examples and to figure out the semantics of the feature.
>
> maybe not completely related, but I made a blog post on using CTFE to unroll foreach at compiletime
>
> https://rsw0x.github.io/post/switch-unrolling/
>
> I find myself often writing recursive templates for compile-time generation of constructs that could be done cleaner with static foreach.

I also use this method alot, and sometimes encounter this "bug": http://dpaste.dzfl.pl/16af3c5dad73

The break inside the `foreach` is breaking from the `foreach`, not from the `switch`, so it continues to execute the `default` clause.

This is not really a bug - `foreach` unrolling is more of a loop unrolling optimization that we hijack, so it makes sense `break` inside it will act like it's inside a regular `foreach`. With `static foreach`, we might want `break`(and `continue`) to operate on the containing, runtime control structure.

On Tuesday, 9 June 2015 at 00:01:07 UTC, Idan Arye wrote:
> On Monday, 8 June 2015 at 22:15:32 UTC, rsw0x wrote:
>> On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
>>> I'm trying to collect together motivating examples and to figure out the semantics of the feature.
>>
>> maybe not completely related, but I made a blog post on using CTFE to unroll foreach at compiletime
>>
>> https://rsw0x.github.io/post/switch-unrolling/
>>
>> I find myself often writing recursive templates for compile-time generation of constructs that could be done cleaner with static foreach.
>
> I also use this method alot, and sometimes encounter this "bug": http://dpaste.dzfl.pl/16af3c5dad73
>
> The break inside the `foreach` is breaking from the `foreach`, not from the `switch`, so it continues to execute the `default` clause.
>
> This is not really a bug - `foreach` unrolling is more of a loop unrolling optimization that we hijack, so it makes sense `break` inside it will act like it's inside a regular `foreach`. With `static foreach`, we might want `break`(and `continue`) to operate on the containing, runtime control structure.

I knew there was something I was forgetting in that short example, thanks for the reminder.

Interestingly, the assembly generated with `break` and `break label` with a label on the switch is exactly the same. I don't have time right now to go review the spec, so I have no idea if that's correct.

On Tuesday, 9 June 2015 at 00:48:34 UTC, rsw0x wrote:
> On Tuesday, 9 June 2015 at 00:01:07 UTC, Idan Arye wrote:
>> On Monday, 8 June 2015 at 22:15:32 UTC, rsw0x wrote:
>>> On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
>>>> I'm trying to collect together motivating examples and to figure out the semantics of the feature.
>>>
>>> maybe not completely related, but I made a blog post on using CTFE to unroll foreach at compiletime
>>>
>>> https://rsw0x.github.io/post/switch-unrolling/
>>>
>>> I find myself often writing recursive templates for compile-time generation of constructs that could be done cleaner with static foreach.
>>
>> I also use this method alot, and sometimes encounter this "bug": http://dpaste.dzfl.pl/16af3c5dad73
>>
>> The break inside the `foreach` is breaking from the `foreach`, not from the `switch`, so it continues to execute the `default` clause.
>>
>> This is not really a bug - `foreach` unrolling is more of a loop unrolling optimization that we hijack, so it makes sense `break` inside it will act like it's inside a regular `foreach`. With `static foreach`, we might want `break`(and `continue`) to operate on the containing, runtime control structure.
>
> I knew there was something I was forgetting in that short example, thanks for the reminder.
>
> Interestingly, the assembly generated with `break` and `break label` with a label on the switch is exactly the same. I don't have time right now to go review the spec, so I have no idea if that's correct.

Why wouldn't they? If we neglect RAII(for simplicity), `break` jumps to the first instruction after the `foreach`, and `break label` with a label on the `switch` jumps to the first instruction after the `switch`. Since there is nothing in the `switch` after the `foreach`, the first instruction after the `foreach` is also the first instruction after the `switch`, so the command to jump to that instruction is the same, and the assembly is the same.

On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
> Walter and I are looking at ways to implement it. Here's a baseline without static foreach - a "trace" function that prints function calls before they are made:
>
> http://dpaste.dzfl.pl/762c83c7fe30
>
> If the function is overloaded, that won't work. In such cases, static foreach might be helpful. Here's code from the cycle "I have a dream":
>
> http://dpaste.dzfl.pl/82a70c809210
>
> I'm trying to collect together motivating examples and to figure out the semantics of the feature.
>
>
> Andrei

There was also http://wiki.dlang.org/DIP57 and relevant discussion thread

On Monday, 8 June 2015 at 22:12:06 UTC, Idan Arye wrote:
> On Monday, 8 June 2015 at 21:32:52 UTC, Timon Gehr wrote:
>> I think the body should have access to a scope that is hidden from the outside which contains the loop variable, but declarations should be inserted into the enclosing scope like for static if.
>
> This would require some syntax to mark the declarations we want to expose. Maybe `out`?
>
> This is far better than the mixin template approach, since it'll alert us early about conflicts:
>
>     static foreach (ident; ["a", "b", "a"])
>     {
>         int mixin(ident ~ "1");
>         out int mixin(ident ~ "2");
>     }
>
> `a1` is created twice, but that's OK since it isn't marked with `out`. `a2` is declared twice and raises a compilation error because it's marked with `out`. This will ensure these kind of errors are detected early and the compilation error points to the exact place of declaration.

    static foreach (ident; ["a", "b", "a"])
    {
        private int mixin(ident ~ "1");
        int mixin(ident ~ "2");
    }

On Monday, 8 June 2015 at 20:02:11 UTC, Andrei Alexandrescu wrote:
> I'm trying to collect together motivating examples and to figure out the semantics of the feature.
>
>
> Andrei

Could something like this fly?

struct weird
{
  void xxx()(T val) if(T.sizeof <= 8);
  void xxx()(const auto ref T val) if(T.sizeof > 8);

  // would require something similar to getOverloads but for templates...?
  static foreach(decl; __traits(getTemplates, typeof(this), "xxx"))
  {
    // impl xxx only once
  }
}

Or is there a better way to accomplish the above?

Daniel