Does D have too many features?

[deadalnix]

Le 30/04/2012 11:17, SomeDude a écrit :
> 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);
>

Exactly.

> 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.

It isn't a good idea.