Tsoding - How Not to Market Your Language Features (page 3) - D Programming Language Discussion Forum

On 3/31/25 13:23, Patrick Schluter wrote: > On Thursday, 27 March 2025 at 14:21:11 UTC, Ali Çehreli wrote: >> I haven't watched it yet. I'm just attempting to beat you to announce it. :p >> >> https://www.youtube.com/watch?v=_kRsbu82zqs >> >> Ali > > I was wondering. At around 1:20:00 he is experimenting with opApply() to make his Array foreach-able. He makes an obvious error of shadowing i parameter with the loop index i. I was wondering why the compiler didn't catch this shadowing as it does in general do recognize shadowed variables. Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`.

On Wednesday, 2 April 2025 at 15:16:43 UTC, Timon Gehr wrote: > On 3/31/25 13:23, Patrick Schluter wrote: >> On Thursday, 27 March 2025 at 14:21:11 UTC, Ali Çehreli wrote: >>> I haven't watched it yet. I'm just attempting to beat you to announce it. :p >>> >>> https://www.youtube.com/watch?v=_kRsbu82zqs >>> >>> Ali >> >> I was wondering. At around 1:20:00 he is experimenting with opApply() to make his Array foreach-able. He makes an obvious error of shadowing i parameter with the loop index i. I was wondering why the compiler didn't catch this shadowing as it does in general do recognize shadowed variables. > > Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. I can't point to the timestamp, but FWIW I do recall seeing something similarly dubious while he was coding.

On Wednesday, 2 April 2025 at 17:01:56 UTC, Derek Fawcus wrote: > On Wednesday, 2 April 2025 at 15:16:43 UTC, Timon Gehr wrote: >> On 3/31/25 13:23, Patrick Schluter wrote: >>> On Thursday, 27 March 2025 at 14:21:11 UTC, Ali Çehreli wrote: >>>> I haven't watched it yet. I'm just attempting to beat you to announce it. :p >>>> >>>> https://www.youtube.com/watch?v=_kRsbu82zqs >>>> >>>> Ali >>> >>> I was wondering. At around 1:20:00 he is experimenting with opApply() to make his Array foreach-able. He makes an obvious error of shadowing i parameter with the loop index i. I was wondering why the compiler didn't catch this shadowing as it does in general do recognize shadowed variables. >> >> Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. > > I can't point to the timestamp, but FWIW I do recall seeing something similarly dubious while he was coding. OK - checking again, I can see the "non shadow" instance you mention. I can see how I would have misinterpreted what he was doing while he was chopping and changing in his code. Maybe it was the same for Patrick? (A version of the code can also be seen at 1:15:54)

On 4/2/2025 8:16 AM, Timon Gehr wrote: > Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. The foreach of an opapply is rewritten by dmd into a delegate. If the shadowing is not detected, this would be why. I actually regret this design. It's overly complex, and I always have to look up how to write an opApply function. It could be done with ranges, if the ranges internally implemented some sort of stack.

On 4/2/25 19:34, Walter Bright wrote: > On 4/2/2025 8:16 AM, Timon Gehr wrote: >> Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. > > The foreach of an opapply is rewritten by dmd into a delegate. If the shadowing is not detected, this would be why. > ... Well, there is this case, but I don't find anything like this in the video near 1:20:00: ```d struct S{ int opApply(int delegate(int) dg){ foreach(k;0..10) if(auto r=dg(k)) return r; return 0; } } void foo(int i){ foreach(i;S()){} // not detected } void main(){ foo(2); } ```

On Wednesday, 2 April 2025 at 17:34:11 UTC, Walter Bright wrote: > On 4/2/2025 8:16 AM, Timon Gehr wrote: >> Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. > > The foreach of an opapply is rewritten by dmd into a delegate. If the shadowing is not detected, this would be why. > > I actually regret this design. It's overly complex, and I always have to look up how to write an opApply function. > > It could be done with ranges, if the ranges internally implemented some sort of stack. Other than the perceived complexity, is there any other issue with the approach? It actually struck me as reasonably sensible. Interestingly, the Go maintainers essentially took the same approach to generalizing their "for ... range" mechanism.

16 hours ago

Re: Tsoding - How Not to Market Your Language Features

Posted by Patrick Schluter
in reply to Timon Gehr

Permalink

Patrick Schluter

Posted in reply to Timon Gehr

Permalink

On Wednesday, 2 April 2025 at 15:16:43 UTC, Timon Gehr wrote:

On 3/31/25 13:23, Patrick Schluter wrote:

On Thursday, 27 March 2025 at 14:21:11 UTC, Ali Çehreli wrote:

I haven't watched it yet. I'm just attempting to beat you to announce it. :p

https://www.youtube.com/watch?v=_kRsbu82zqs

Ali

I was wondering. At around 1:20:00 he is experimenting with opApply() to make his Array foreach-able. He makes an obvious error of shadowing i parameter with the loop index i. I was wondering why the compiler didn't catch this shadowing as it does in general do recognize shadowed variables.

Can you show the code that you mean or give a more accurate time stamp? I only see the delegate's parameter i at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within opApply is dg.

Timestamp 1:17:27

int opApply(scope int delegate(size_t i, size_t a, size_t b, ref T) dg) {
    for (size_t i = 0; i < length; ++i) {
        int result = dg(i, 69, 420, items[i]);
        if (result) return result;
    }
    return 0;
}

Ok, now that I have typed the code, I see why there is no shadowing. The size i as parameter of the delegate declaration is just that, a declaration, not a definition.
During video viewing, it went by so fast that it looked like a parameter list of opApply.

On Wednesday, 2 April 2025 at 17:34:11 UTC, Walter Bright wrote: > On 4/2/2025 8:16 AM, Timon Gehr wrote: >> Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. > > The foreach of an opapply is rewritten by dmd into a delegate. If the shadowing is not detected, this would be why. There was no shadowing. It only looked like one when glancing quickly over the code. My bad. > > I actually regret this design. It's overly complex, and I always have to look up how to write an opApply function. > > It could be done with ranges, if the ranges internally implemented some sort of stack.

On Wednesday, 2 April 2025 at 17:26:59 UTC, Derek Fawcus wrote: > On Wednesday, 2 April 2025 at 17:01:56 UTC, Derek Fawcus wrote: >> On Wednesday, 2 April 2025 at 15:16:43 UTC, Timon Gehr wrote: >>> On 3/31/25 13:23, Patrick Schluter wrote: >>>> [...] >>> >>> Can you show the code that you mean or give a more accurate time stamp? I only see the _delegate's_ parameter `i` at 1:19:41, which does not lead to shadowing, as the only actual parameter in scope within `opApply` is `dg`. >> >> I can't point to the timestamp, but FWIW I do recall seeing something similarly dubious while he was coding. > > OK - checking again, I can see the "non shadow" instance you mention. > > I can see how I would have misinterpreted what he was doing while he was chopping and changing in his code. Maybe it was the same for Patrick? Indeed, it was exactly that. I really don't like using i,j or k in a function parameter list, in my world they are reserved for loop indices. This has the consequence that code that violate that rule always appear suspicious to me. > > (A version of the code can also be seen at 1:15:54)

Forums