Multiple delegates, contextual delegates

[Aphex]

On Wednesday, 26 June 2019 at 12:51:29 UTC, XavierAP wrote:
> On Wednesday, 26 June 2019 at 12:16:19 UTC, Aphex wrote:
>> On Wednesday, 26 June 2019 at 09:48:35 UTC, angel wrote:
>>>
>>> Indeed it looks like a library solution.
>>> Its alleged usefulness has nothing to do with being a library 
>>> as opposed to being a part of the core language. Normally, 
>>> the core language implements stuff that is very hard or very 
>>> ugly to implement in a library, and your proposal will look 
>>> perfect in a library implementation.
>>
>> 1. The problem with a library solution is that it requires it 
>> part of the library. This is not alway effective. It would 
>> need to be part of phobos so at least it is used every. Not 
>> everything is a candidate for libraries even if they work in 
>> libraries. Virtually everything can, in theory, be a library 
>> solution. One could have make delegates a library solution, it 
>> is possible and functional... but it is too common and it 
>> loses functionality.
>>
>>
>> 2. It is a direct extension of something that is already a 
>> core semantic in the compiler and since it can be directly 
>> extend the keyword `delegate` with being 100% backwards 
>> compatible, splitting it in to a library prevents such a 
>> useful extension.
>
> The problem is that "delegates" are not so core to D (unlike C# 
> for example). D has delegates proper, function pointers, 
> anything that implements opCall, etc. Under the hood they are 
> completely different. The most common solution in current D is 
> duck-typed templates and alias parameters; I think  very few 
> people use delegates proper in D in practice. And the direction 
> is not clear even in the spec:
>

This is simply factually false. Delegates are extremely 
fundamental to do. They are used everywhere. Lambdas are 
delegates, member functions are essentially delegates, many 
templates take lambas. Lazy instantiation use delegates. 
Delegates are everywhere. Functions are delegates that do capture 
the context implicitly(and so can be optimized) and member 
functions have their context passed as an argument implicitly.


> https://dlang.org/spec/function.html#closures
> «Future directions: Function pointers and delegates may merge 
> into a common syntax and be interchangeable with each other.»

> Another secondary point is why do you need this into an 
> overloaded operator. Giving new meanings to old operators makes 
> the code a little bit shorter but possibly less clear. I 
> believe Walter picked ~ instead of + for string concatenation 
> for this reason, so even in the std library the operator 
> overloading is going to be a tough sell.

Because it was an example, something has to be used. I prefer + 
because it make sense and is used with -. ~ has no dual so it is 
less descriptive that it has a corresponding remove behavior.

~ used with strings makes sense because it is concatenation and 
one generally does not deconcatenate... but containers += and -= 
make more sense...

In any case the specific symbols are totally irrelevant. In fact, 
I've started using þµÆ etc. I write all my identifiers in 
extended ascii and make them unreadable so my code is hard to 
follow... but it is irrelevant because symbols do not have any 
inherent meaning.