On Thursday, 30 July 2020 at 06:08:07 UTC, Walter Bright wrote:
> On 7/29/2020 8:23 PM, Mathias LANG wrote:
>> On Thursday, 30 July 2020 at 03:16:02 UTC, Walter Bright wrote:
>>> On 7/29/2020 4:26 AM, Dennis wrote:
>>>> How would you solve this if you were the library author?
>>>
>>> The usual way is with templates.
>> 
>> It doesn't work for `Object.toString` which is the textbook use case for this.
>
> That's really a problem with Object.toString.

Object.toString is just an example.
The problem is that sometimes, you can't template. Like when using classes.
So the inherent problem is, how do we compose attributes and non-template-able code ?

Note that if you are using templates, DIP1032 has little benefit either, because you can just template the delegate so the attributes are infered.

On Thursday, 30 July 2020 at 03:16:02 UTC, Walter Bright wrote:
> On 7/29/2020 4:26 AM, Dennis wrote:
>> How would you solve this if you were the library author?
>
> The usual way is with templates.

That will not work here, opApply is a virtual function.

It also breaks in cases where the parameter type is not specified:

```
new Tree().opApply(x => 0); // works with delegate
// with template: opApply cannot deduce function from argument types !()(void)
```

This is not a hypothetical situation, I had to deal with this when making std.bigint @safe, because a project on buildkite broke.
https://github.com/dlang/phobos/blob/f5197c82e7b0d1fad2f37233a72f46a56f3f17eb/std/bigint.d#L1330

Then there's other scenarios where you can't use templates:
- Library is compiled as a shared lib
- Library is closed source
- Library has extern(System) interface (e.g. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumdisplaymonitors)

On Thursday, 30 July 2020 at 03:16:02 UTC, Walter Bright wrote:
> On 7/29/2020 4:26 AM, Dennis wrote:
>> How would you solve this if you were the library author?
>
> The usual way is with templates.

Did you even try his example code with templates? Or do you just give an answer without even trying to see if it will work? Sometimes it feels like you only program in D using a feature set that is more similar to C and you aren't aware of the actual problems with some of D features (cause you don't use them). Not surprising opApply() isn't used once in DMD's source.

Now sure DMD came from C, even though it's been written in D for quite a while. I searched the commits you have made in phobos. You've made a total of 6 commits that contain *changes* to a line that contained opApply. One was just a tab->spaces whitespace fix. Three were just changing attributes of existing opApply functions eg adding `scope`. One was just a comment change.

There wasn't a single commit where you used opApply on your own. So I'm not surprised you don't understand the problem. You probably literally have never used opApply, so obviously you have no awareness of the problems actual users have with the features involved.