[Issue 2159] Confusion between function call and C++ style function address

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=2159

tyckesak <josipp at live.de> changed:

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

--- Comment #15 from tyckesak <josipp at 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!

--