On 4/23/2020 11:00 PM, Manu wrote:
> [...]

Please do not re-quote every ancestor of the thread. Just quote enough to give context. I do know how to use the threaded view of the n.g. reader if I need more context.

On 4/23/2020 11:00 PM, Manu wrote:
> I guess this is the key case you need to solve for:
> 
>    template T(Args...) {}
>    T!(Tup)     -> T!(0, 1, 2)
>    T!(Tup)...  -> T!0, T!1, T!2
> 
> And the parallel expansion disambiguation is also critical:
>    T!(Tup, Tup2...)...  -> T!(0, 3, 4, 5), T!(1, 3, 4, 5), T!(2, 3, 4, 5)
> 
> If you can solve those, the rest will probably follow.

Fair enough. Though there needs to be a rationale as to why those two particuler cases are needed and critical.

On Friday, 24 April 2020 at 04:15:36 UTC, Walter Bright wrote:
> Ok, I've had a chance to think about it. It's a scathingly brilliant idea!
>
>
> The AST doesn't have to be walked to make this work, just do it as part of the usual bottom-up semantic processing.
>

I honestly don't care about which syntax we chose, but I care about having the expansion logic be centralized in the compiler.
It almost sounds like you want to make the an inline part of the regular semantic pass.
If that is done, it's going to be hard to change if we discover that special handling is needed for particular nodes/node combinations `.tupleof` comes to mind.

I should also note that the DIP does reduce the size of the trees to sqrt(N) if the most of the size came from recursive instantiations of staticMap.
Therefore a bottom-up work if the subtree is not particularly expensive when compared to having a weaker more inflexible version of this feature.

On Friday, 24 April 2020 at 08:25:01 UTC, Stefan Koch wrote:

> Therefore a bottom-up work if the subtree
Therefore a bottom-up walk of the sub-tree

On Friday, 24 April 2020 at 08:26:41 UTC, Stefan Koch wrote:
> On Friday, 24 April 2020 at 08:25:01 UTC, Stefan Koch wrote:
>
>> Therefore a bottom-up work if the subtree
> Therefore a bottom-up walk of the sub-tree

Argh. I meant top-down walk.

On Friday, 24 April 2020 at 08:26:41 UTC, Stefan Koch wrote:
> On Friday, 24 April 2020 at 08:25:01 UTC, Stefan Koch wrote:
>
>> Therefore a bottom-up work if the subtree
> Therefore a bottom-up walk of the sub-tree

I meant top-down walk.

On Fri, Apr 24, 2020 at 6:20 PM Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 4/24/2020 12:39 AM, Manu wrote:
> > It doesn't make much sense to think in terms of primitive types. As I
> just said
> > (but you truncated), operator overloads are almost certainly part of
> this equation.
>
> Operator overloads don't change it.
>

This claim doesn't make sense. A custom type can BinOp any adjacent type it likes.

> I think it's more common to do a fold like this with logical operators though;
> > `&&` appears 9 times out of 10 in my code.
>
>      [ cast(bool)Tup ]
>

And then fold them?

On 4/24/2020 1:24 AM, Walter Bright wrote:
> On 4/23/2020 11:00 PM, Manu wrote:
>> I guess this is the key case you need to solve for:
>>
>>    template T(Args...) {}
>>    T!(Tup)     -> T!(0, 1, 2)
>>    T!(Tup)...  -> T!0, T!1, T!2
>>
>> And the parallel expansion disambiguation is also critical:
>>    T!(Tup, Tup2...)...  -> T!(0, 3, 4, 5), T!(1, 3, 4, 5), T!(2, 3, 4, 5)
>>
>> If you can solve those, the rest will probably follow.
> 
> Fair enough. Though there needs to be a rationale as to why those two particuler cases are needed and critical.

Please keep in mind that the following works today:

  void foo(int);

  template tuple(T...) { enum tuple = T; }

  void test() {
    auto t = tuple!(1, 2, 3);
    static foreach (i, e; t)
        foo(e + i);
  }

and generates:

  void test() {
     foo(1); foo(3); foo(5);
  }

On Friday, 24 April 2020 at 08:35:53 UTC, Walter Bright wrote:
> On 4/24/2020 1:24 AM, Walter Bright wrote:
>> On 4/23/2020 11:00 PM, Manu wrote:
>>> [...]
>> 
>> Fair enough. Though there needs to be a rationale as to why those two particuler cases are needed and critical.
>
> Please keep in mind that the following works today:
>
>   void foo(int);
>
>   template tuple(T...) { enum tuple = T; }
>
>   void test() {
>     auto t = tuple!(1, 2, 3);
>     static foreach (i, e; t)
>         foo(e + i);
>   }
>
> and generates:
>
>   void test() {
>      foo(1); foo(3); foo(5);
>   }

Because of implementation issues in static foreach that'll take forever.
Note: those issues are actually impossible to slove in the general case.

On Fri, Apr 24, 2020 at 6:40 PM Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 4/24/2020 1:24 AM, Walter Bright wrote:
> > On 4/23/2020 11:00 PM, Manu wrote:
> >> I guess this is the key case you need to solve for:
> >>
> >>    template T(Args...) {}
> >>    T!(Tup)     -> T!(0, 1, 2)
> >>    T!(Tup)...  -> T!0, T!1, T!2
> >>
> >> And the parallel expansion disambiguation is also critical:
> >>    T!(Tup, Tup2...)...  -> T!(0, 3, 4, 5), T!(1, 3, 4, 5), T!(2, 3, 4,
> 5)
> >>
> >> If you can solve those, the rest will probably follow.
> >
> > Fair enough. Though there needs to be a rationale as to why those two
> particuler
> > cases are needed and critical.
>
> Please keep in mind that the following works today:
>
>    void foo(int);
>
>    template tuple(T...) { enum tuple = T; }
>
>    void test() {
>      auto t = tuple!(1, 2, 3);
>      static foreach (i, e; t)
>          foo(e + i);
>    }
>
> and generates:
>
>    void test() {
>       foo(1); foo(3); foo(5);
>    }
>

static foreach is not an expression, and it's very hard to involve those
result calls in some conjunction. Expand that code to || them together...
it gets ugly real fast.
I wouldn't have wasted my time writing this DIP and a reference
implementation if static foreach was fine.

Find instances of `staticMap` in phobos and/or user code, and show how you can replace them with static foreach, then there's something to talk about.