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
