Hidden argument kind antipattern

[Bruno Medeiros]

On 20/04/2011 00:09, Vladimir Panteleev wrote:
> To elaborate, I mean allowing code which appears to behave surprisingly
> different from the at-a-glance interpretation, unless the programmer
> knows the function's signature. I've noticed a worrying adoption in D of
> this "antipattern", which, frankly, I believe doesn't belong in a
> well-designed programming language. One classic example of this is
> passing arguments by reference, something D inherited from C++. For
> example:
>
> int x, y;
> // ...
> someObject.updateCoords(x, y);
>
> What can you say about this code? The unobvious and surprising
> interpretation of it is that updateCoords will change the values of x
> and y. C# solved this problem neatly by requiring to specify the "ref"
> keyword before the function arguments:
>
> someObject.updateCoords(ref x, ref y); // much clearer
>
> This problem carries over to lazy parameters, as well. I'll quote a line
> of code from a recent post by David Simcha:

This problem is also very similar to the named arguments problem 
(figuring out which argument corresponds to which parameter when there 
are many parameters and they all have the same type).

My response is the same as the named arguments issue: I think it is 
preferable (if not preferable, then at least sufficiently good) to use 
an IDE to look up the full function signature, than to make language 
additions to make the call clearer by just looking at the source text.

Your post actually adds a bit more value to my approach, because it 
shows my approach is the same no matter what you want to figure out 
about the arguments (if they are ref, lazy, to which named parameter the 
argument corresponds, etc.), and it also brings up the full DDoc with 
the full information describing what the function does.
Conversely, your approach does not scale in a sense, because you need to 
keep adding stuff for each new thing you want to know about the 
parameter (ref, lazy, named argument, etc.). Should we add variadic 
parameters to the mix as well? What else? Taking this approach to the 
extreme, we might as well replicate all the information in the function 
signature in the function call...

-- 
Bruno Medeiros - Software Engineer