Thread overview
[Issue 2159] Confusion between function call and C++ style function address
May 15, 2018
Dmitry Olshansky
May 16, 2018
anonymous4
Oct 10, 2019
RazvanN
Oct 24, 2019
RazvanN
Oct 25, 2019
anonymous4
Oct 25, 2019
anonymous4
Oct 25, 2019
RazvanN
Oct 28, 2019
anonymous4
Apr 03, 2022
tyckesak
Dec 17, 2022
Iain Buclaw
May 15, 2018
https://issues.dlang.org/show_bug.cgi?id=2159

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |dmitry.olsh@gmail.com
         Resolution|---                         |WORKSFORME

--- Comment #8 from Dmitry Olshansky <dmitry.olsh@gmail.com> ---
import core.thread;

void main()
{
        int g;
        int run()
        {
                for(int i = 0; i < 1000; ++i)
                        ++g;
                return 0;
        }
        auto t = new Thread(run);
        t.start;
        t.wait;
}

Now it doesn't fail and I fail to see how we fix the general since optional parens became a thing after UFCS was finally fully implemented.

--
May 16, 2018
https://issues.dlang.org/show_bug.cgi?id=2159

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec
             Status|RESOLVED                    |REOPENED
           Hardware|x86                         |All
         Resolution|WORKSFORME                  |---
                 OS|Windows                     |All

--- Comment #9 from anonymous4 <dfj1esp02@sneakemail.com> ---
> Now it doesn't fail
Then it's a subtle bug that can ship to the user.

> and I fail to see how we fix the general since optional
> parens became a thing after UFCS was finally fully implemented.
The compiler can detect overload ambiguity between constructors taking int and function pointer.

> This might be okay for no-argument methods
FWIW, C# takes method delegates without ampersand syntax much like C does for functions.

--
October 10, 2019
https://issues.dlang.org/show_bug.cgi?id=2159

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #10 from RazvanN <razvan.nitu1305@gmail.com> ---
Compiling:

import core.thread;

void main()
{
        int g;
        int run()
        {
                for(int i = 0; i < 1000; ++i)
                        ++g;
                return 0;
        }
        auto t = new Thread(run);
        t.start;
        t.wait;
}

Yields:

test.d(11): Error: class core.thread.Thread member this is not accessible
test.d(13): Error: no property wait for type core.thread.Thread

Is this satisfactory?

--
October 24, 2019
https://issues.dlang.org/show_bug.cgi?id=2159

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--
October 25, 2019
https://issues.dlang.org/show_bug.cgi?id=2159

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #11 from anonymous4 <dfj1esp02@sneakemail.com> ---
Self-contained test case:
---
void f(int);
void f(int function());
int g();
void h()
{
    f(g);
    f(&g);
}
---

--
October 25, 2019
https://issues.dlang.org/show_bug.cgi?id=2159

--- Comment #12 from anonymous4 <dfj1esp02@sneakemail.com> ---
If the ambiguity happened spontaneously in phobos, it's plausible it can reemerge or happen elsewhere. Though it's a language change, so it can be required to go through DIP?

--
October 25, 2019
https://issues.dlang.org/show_bug.cgi?id=2159

--- Comment #13 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to anonymous4 from comment #11)
> Self-contained test case:
> ---
> void f(int);
> void f(int function());
> int g();
> void h()
> {
>     f(g);
>     f(&g);
> }
> ---

I don't get it. This code compiles just fine, as it should. f(g) call s f(int)
and f(&g) calls f(int function()). This seems reasonable to me.

--
October 28, 2019
https://issues.dlang.org/show_bug.cgi?id=2159

--- Comment #14 from anonymous4 <dfj1esp02@sneakemail.com> ---
Well, it's an enhancement request. Per the title this code is error prone and ambiguous for people with C background, although it requires specific design to trigger.

--
April 03, 2022
https://issues.dlang.org/show_bug.cgi?id=2159

tyckesak <josipp@live.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josipp@live.de

--- Comment #15 from tyckesak <josipp@live.de> ---
(In reply to Bartosz Milewski from comment #4)
> For me there's no doubt that it's a design flaw in the language and I'll try to explain my reasoning.
> 
> For people coming from C/C++: A function name in C is treated as a function pointer. It's okay for D to make this syntax illegal. It's not okay to give this syntax a completely different meaning (function call), expecially if there are situations where the error is undetectable. I was lucky the the result of run() was too small for the stack size, otherwise my unit test would run without a problem.
> 
> Program understanding: How does the compiler know that "run" is a call and not a variable? Because it has the symbol table. The symbol might be defined arbitrarily far from the point of use. That's fine for the compiler but not for the programmer who's reading somebody else's code. Now the reviewer must chase multiple files in order to figure out if something is a function call or a variable. You can't really say that it shouldn't matter for the reviewer whether a given statement is a function call.
> 
> Notice that the analogous method-call syntax is not bad, because it has a different context. There is always an object involved. Without any knowledge of the symbol table, the programmer assumes that it's an access to a public data member. The fact that it expands to a method call is the matter of the object, whose designer decided to hide this implementation detail. This is very much in the spirit of object-oriented programming--implementation hiding. But there is a well-defined owner/encapsulator of implementation details--the object.
> 
> From the abstract point of view, when you allow a symbol to transparently expand into a function call, you are making a unification. The new abstraction is a "variable or a function call". What is this abstraction? Do you have a name for it? If you don't, it's just a hack that saves two keystrokes and makes the code more obfuscated. Keystroke-saving improvements should not be a design goal in itself.
> 
> Note that there is an analogous abstration for method calls. It's called a "property".
> 
> When we discuss this topic in writing, you use the syntax "run()" rather than "run". That's because you want to be clear that you mean a function call. When you write a program you also communicate with other programmers. You should be as clear about the meaning as you are in our discussion. If I were reviewing somebody else's code I would demand they use the function-call syntax.

I second this wholeheartedly; taking a page from Scala's book, they have
a very similar problem on their hands, and decided to disallow no-parens
invocations
for anything that is not a property at some point: their reasoning was
that the possibility of some call producing side effects must be clearly stated
by treating the invocation as a real function call; after all, that is what
the `pure` attribute is kind of trying to emulate in D, but is completely
undercut
by this language quirk!

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=2159

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--