On Monday, 30 April 2012 at 02:33:35 UTC, H. S. Teoh wrote:
On Sun, Apr 29, 2012 at 11:18:12PM +0200, deadalnix wrote:
[...]
C don't have out parameters as D have. C have pointer to do
kind of
out parameters, and D have pointers too, this is a non issue.
I argue that using 'out' vs. a pointer is a good thing, because
it
clarifies intent. When you see a pointer, it's far from clear
whether
it's an input parameter, an output parameter, or both.
More and more, I'm leaning towards the opinion that all code
should
reveal intent, preferably in a language-supported way. Unclear
intent is
what leads to subtle bugs caused by people calling functions
with wrong
assumptions. (You'd think this should be a non-problem with
programmers,
who are presumably smart enough to figure things out without
being told
in the face, but I've seen too much "enterprise" code by now to
not be
cynical about it.)
T
Of course, a better way would be to change the meaning of the
comma operator to allow a Python-style syntax for return values,
i.e something like
int, Error foo(char[] input, ref Bar){...}
auto res, err = foo(input, bar);
We would then only allow in and inout parameters. This would be
much closer to functional style. There would be no longer any
need for the "in" and "out" keywords.
If we push a little further, you can also get rid of inout by
doing this:
int, ref Bar foo(char[] input, ref Bar){...}
auto out, bar = foo(input, bar);
Every time the compiler sees the same symbol as an input and
output parameter, it can assume it's an inout parameter. This, of
course, would break a lot of code.
