DIP 1011--extern(delegate)--Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

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