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
