www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1011--extern(delegate)--Preliminary Review Round 1

reply Mike Parker <aldacron gmail.com> writes:
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!
Jul 14 2017
next sibling parent Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:

 DIP 1011 is titled "extern(delegate)".


Looks good to me, useful, doesn't brake code, DIP seems correct.
Jul 14 2017
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/14/17 6:43 AM, 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!


It seems reasonable.

One concern I have is this:

extern(delegate) ref int foo(ref int x) { return x; }

int x;

auto dg = &x.foo; // is dg an int * or a delegate?

Currently, this means the former. I'm concerned about ambiguities and 
how to resolve them if all of a sudden someone decides it's a good idea 
to change their functions to extern(delegate), and code like this 
silently switches over. Or someone tries to form a delegate from one of 
these, but instead ends up calling the function instead.

-Steve
Jul 14 2017
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 14 July 2017 at 12:52:56 UTC, Steven Schveighoffer 
wrote:

 On 7/14/17 6:43 AM, 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!


 It seems reasonable.

 One concern I have is this:

 extern(delegate) ref int foo(ref int x) { return x; }

 int x;

 auto dg = &x.foo; // is dg an int * or a delegate?

 Currently, this means the former. I'm concerned about 
 ambiguities and how to resolve them if all of a sudden someone 
 decides it's a good idea to change their functions to 
 extern(delegate), and code like this silently switches over. Or 
 someone tries to form a delegate from one of these, but instead 
 ends up calling the function instead.

 -Steve


I thought about this use case and it's an interesting one.

TLDR; it should return "int delegate()" not "int*"

First I want to say this use case happens less often then you 
might think. It's only a problem when the function has no 
arguments. If the function does have arguments then omitting the 
parameter list clearly means the application wants a 
delegate/function pointer. Currently, taking the address of a 
member function call will return a delegate, even if it returns a 
reference.

import std.stdio;
struct Foo
{
     static int staticInt;
     ref int bar()
     {
         return staticInt;
     }
}

Foo foo;
writeln(typeid(&foo.bar)); // prints "int delegate()"

// NOTE: If you want to take the address of the return value, you 
add the () to the call, i.e.
writeln(typeid(&foo.bar())); // prints "int*"

Furthermore, since taking the address of a UFCS call currently 
has no meaning, this would evaluate to int* if it was a UFCS call:

ref int baz(ref Foo foo)
{
     static int staticInt;
     return staticInt;
}
writeln(typeid(&foo.baz)); // prints "int*"

So the semantic analyzer has a precendence for the '&' operator 
when applied to "dotted" function calls.  It checks if the 
expression could result in a delegate, if not then it falls back 
to taking the address of the return value.

As you have noticed, since extern(delegate) adds meaning to 
taking the address of a UFCS call, the semantic analyzer will now 
be able to create a delegate in a place where it previously 
couldn't.

extern(delegate) ref int baz(ref Foo foo)
{
     static int staticInt;
     return staticInt;
}
writeln(typeid(&foo.baz)); // is it "int*" or "int delegate()"?

The implementation could go either way but I think it should be 
consistent with the semantics for delegates meaning it should 
result in "int delegate()" and here's why:

   * Having an inconsistent precedence for member functions and 
extern(delegate) functions would be confusing

   * If taking the address of the return value has precendence, we 
would have to come up with a new syntax when the application 
wants to do the opposite.  Currently, if the application really 
means they want to take the address of the return value, they can 
simply add an empty parameter list to disambiguate the meaning, 
i.e. they could use &foo.bar() instead of &foo.bar.  If we used 
the opposite precedence, there is currently no way to say we 
really want a delegate instead of taking the address of the 
return value.

   * If an existing project does start using extern(delegate), in 
almost all cases the change from taking the address of the return 
value to getting a delegate will almost always result in a 
compile time error.  In your example if the meaning of &x.foo 
changed, it would return a different type which would very likely 
be caught by the compiler, depending of course on how the value 
is used.  There are cases where it wouldn't be caught, but it's 
very unlikely.

   * This only affects code that goes back and modifies their 
application to use extern(delegate).  In other words, it's not 
breaking existing code unless that existing code itself changes 
to use this feature.
Jul 14 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/14/17 1:18 PM, Jonathan Marler wrote:

 On Friday, 14 July 2017 at 12:52:56 UTC, Steven Schveighoffer wrote:

 On 7/14/17 6:43 AM, 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!


 It seems reasonable.

 One concern I have is this:

 extern(delegate) ref int foo(ref int x) { return x; }

 int x;

 auto dg = &x.foo; // is dg an int * or a delegate?

 Currently, this means the former. I'm concerned about ambiguities and 
 how to resolve them if all of a sudden someone decides it's a good 
 idea to change their functions to extern(delegate), and code like this 
 silently switches over. Or someone tries to form a delegate from one 
 of these, but instead ends up calling the function instead.


 
 I thought about this use case and it's an interesting one.
 
 TLDR; it should return "int delegate()" not "int*"


I can say from experience, this can wreak havoc on things like template 
constraints. Changing behavior subtly for the same syntax has consequences.

I wonder if there should be a deprecation period. It's an odd case, 
because it only happens if the declaration is changed to 
extern(delegate), which means before the change would be introduced, no 
code would break.

But I fully see quite a few people doing this because people write a lot 
of UFCS functions these days, and slapping an extern(delegate): label 
for these functions might be just the blunt instrument people reach for.

I also see people doing &foo.someUFCSFunc without realizing it's not 
going to create a delegate. It may be obvious to the compiler that it's 
wrong, so they may still get an error. Where I see possible problems is 
things like template constraints (e.g. if(is(typeof(&foo.f) == int *)) )

However, we do have precedent that &func is different for  property 
functions vs. normal ones, so there is some validity to your chosen 
path. And the opposite choice (int *) would make it impossible to take a 
delegate to such a function.

-Steve
Jul 14 2017
prev sibling next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:

 DIP 1011 is titled "extern(delegate)".


Looks good!
Jul 14 2017
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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


  Contrary to  other poster I believe this is wrong way to solve a 
problem. A far simpler approach is to allow compiler implicitly 
convert function pointer to delegate. The dance with making an 
ABI wrapper can be left to compiler proper.

And no annotation hell.

---
Dmitry Olshansky
Jul 14 2017
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/14/17 1:02 PM, Dmitry Olshansky 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


 
   Contrary to  other poster I believe this is wrong way to solve a 
 problem. A far simpler approach is to allow compiler implicitly convert 
 function pointer to delegate. The dance with making an ABI wrapper can 
 be left to compiler proper.
 
 And no annotation hell.


But I think the idea is to avoid the extra indirection and call, no? We 
already have toDelegate, which works fine if you don't care about that.

-Steve
Jul 14 2017
prev sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 14 July 2017 at 17:02:37 UTC, Dmitry Olshansky wrote:

 ...The dance with making an ABI wrapper can be left to compiler 
 proper.


This proposal doesn't make ABI wrappers, it changes the ABI of 
the function itself.
Jul 14 2017
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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(?)?
Jul 16 2017
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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;
     */
}
Jul 17 2017
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 24 2017
prev sibling parent reply Andrea Fontana <nospam example.com> writes:
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
Jul 24 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 24 2017
parent reply Andrea Fontana <nospam example.com> writes:
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
Jul 25 2017
parent reply =?UTF-8?B?c29vbGHDr21hbg==?= <sahmi.soulaimane gmail.com> writes:
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.
Jul 21 2018
parent Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jul 22 2018