Hidden argument kind antipattern

[spir]

On 04/20/2011 01:53 AM, dsimcha wrote:
> On 4/19/2011 7:30 PM, spir wrote:
>> And what about requiring "lazy" (and "ref") at the call site; I mean in
>> the long term? I find this very sensible.
>>
>> Denis
>
> I wouldn't mind this for "lazy" but would argue heavily against it for "ref".
> ref parameters are both more frequently used and less surprising than lazy
> parameters and usually the name and usage of the function give a stronger hint
> about what it does. Secondly, functions may modify their input parameters in
> surprising ways without ref, if the parameters contain indirection (for
> example, classes, pointers, arrays). Furthermore, requiring ref at the call
> site would break uniform function call syntax. For example:
>
> void popFront(T)(ref T[] array) {
> array = array[1..$];
> }
>
> void main() {
> auto foo = [1, 2, 3];
> foo.popFront();
> }

I rather agree in this case; this is due to correct naming of the called 
function. See the example of calling std.utf.decode in my reply to Kai Meyer. 
Another example:

void first(T)(ref T[] array) {
     auto elem = array[0];
     array = array[1..$];
     return elem;
}

void main() {
     auto foo = [1, 2, 3];
     auto elem = first(foo);
     // or even:
     while (foo.length > 0)
         writeln(first(foo));
}

I think Vladimir's point of the actual task performed by a function beeing 
"surprising" is valid.

Now, it's true this would break UFCS, here foo.first(). But note that this is 
OO-like call syntax, and commonly in OO the receiver is passed by ref 
(precisely for beeing changeable, I guess); the object on which a method 
applies is not a (normal) parameter. Also, the more UFCS gets discussed, the 
more is raises questions, for debattable advantage.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com