On Sunday, 16 July 2017 at 11:45:09 UTC, Nicholas Wilson wrote:
> On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:
>> DIP 1011 is titled "extern(delegate)".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 28 (3:59 AM GMT July 29), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> Not that it is a requirement to consider fir this DIP, but how would this play with Vittorio's lambda Value capture DIP(?)?

I don't see any relation.  Looks like the lambda capture lowers to defining a temporary struct and assigning the captured values to fields in that struct, then the lambda is defined as a member function of that struct.  That member function already uses the delegate ABI where the context is a reference to the temporary struct.

void main()
{
    int x;
    string s;

    auto dg = [x,s]() => {
        // ...
    }
    /*
    lowers to something like this
    struct __lambda_struct__
    {
        int x;
        string s;
        // This method already has a context, cannot make it extern(delegate)
        void execute()
        {
            // ...
        }
    }
    auto dg = &__lambda_struct__(x, s).execute;
    */
}

On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:
> DIP 1011 is titled "extern(delegate)".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 28 (3:59 AM GMT July 29), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

I don't like it so much but also something like this could be considered:

out!(x => x>0)
or
out!x(x > 0)

that can't collide with current syntax

On Monday, 17 July 2017 at 15:16:45 UTC, Jonathan Marler wrote:
> On Sunday, 16 July 2017 at 11:45:09 UTC, Nicholas Wilson wrote:
>> [...]
>
> I don't see any relation.  Looks like the lambda capture lowers to defining a temporary struct and assigning the captured values to fields in that struct, then the lambda is defined as a member function of that struct.  That member function already uses the delegate ABI where the context is a reference to the temporary struct.
>
> [...]

Fair enough.

On 7/24/17 7:08 AM, Andrea Fontana wrote:
> On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:
>> DIP 1011 is titled "extern(delegate)".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 28 (3:59 AM GMT July 29), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
> 
> I don't like it so much but also something like this could be considered:
> 
> out!(x => x>0)
> or
> out!x(x > 0)
> 
> that can't collide with current syntax

I think you meant this for DIP 1009?

-Steve

On Monday, 24 July 2017 at 15:27:10 UTC, Steven Schveighoffer wrote:
>> I don't like it so much but also something like this could be considered:
>> 
>> out!(x => x>0)
>> or
>> out!x(x > 0)
>> 
>> that can't collide with current syntax
>
> I think you meant this for DIP 1009?
>
> -Steve

You're right, I had too many windows opened :)

Andrea

I know this one year old already but the DIP is still in formal review.

I Think the inability to create a delegate with a custom object as its context similar to delegates created from member functions should be fixed in a library solution rather than making a language change. A simple implementation that you could try:
```
import std.traits;


@system ReturnType!F delegate(Parameters!F[1..$]) makeExternDelegate(F)(F fp, void* this_) {
    struct Delegate { void* ctxptr; F fptr; }
    auto dlg = Delegate(this_, fp);
    auto _tmp = cast(void*) &dlg;
    auto dlgp = cast(typeof(return)*) _tmp;
    return *dlgp;
}

unittest
{
    struct O { int val; }
    auto objp = new O(1);
    static int getVal(O* this_) {return this_.val;}
    auto dlg = makeExternDelegate(&getVal, objp);
    dlg();
    assert(dlg() == 1);
    objp.val = 1123;
    assert(dlg() != 1);
    assert(dlg() == 1123);
}
```

However I think the compiler should still disambiguate the output of the addressof (&) operator between free and member functions, I find the difference to be rather an implementation detail that a user should not have to worry about. I also find this DIP to be like an awkward deprecation process for such disambiguation. Perhaps this should rather be on the list of breaking changes of D3. D3 would be where the language would grow up from past mistakes, even if that should break compatibility with C! I know, no body cares about that.

On Saturday, 21 July 2018 at 17:54:17 UTC, soolaïman wrote:
> I know this one year old already but the DIP is still in formal review.
>
> [...]

This doesn't work because the ABI of a normal function is NOT THE SAME as the ABI of a delegate.  That's the only reason the DIP exists is to solve this ABI problem.