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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat Jun 28 11:49:47 PDT 2008


http://d.puremagic.com/issues/show_bug.cgi?id=2159


bartosz at relisoft.com changed:

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




------- Comment #4 from bartosz at relisoft.com  2008-06-28 13:49 -------
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. 



More information about the Digitalmars-d-bugs mailing list