A nice way to step into 2012

Timon Gehr timon.gehr at gmx.ch
Wed Dec 28 13:29:56 PST 2011


On 12/28/2011 09:57 PM, Jonathan M Davis wrote:
> On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
>>> I also don't think that they add much unless you have functions with way
>>> too many parameters, and those sorts of functions shouldn't be
>>> happening anyway. And I don't like the additional complication of the
>>> possibility of reordering functiion arguments. You should be able to
>>> look at a function and know which parameters its arguments go with
>>> purely by the order, which named arguments destroy.
>> Why would that be beneficial?
>
> I'd hate to have a function like
>
> void func(float x, float y);
>
> where calling it
>
> func(1.0, 2.0);
>
> and
>
> func(y : 1.0, x : 2.0);
>
> don't do the same thing. All of a sudden, I have to pay attention to what
> names the arguments were given.  I can't just read the function call like I
> would now. It becomes error-prone in that regard and violates the current
> expectations of argument order.  It will make code harder to read for minimal
> benefit IMHO. I do _not_ think that name arguments are an improvement.
>

So it is the usual "because the feature can be misused it is bad" argument?

>>> But all of that has been discussed at length before. I'm completely
>>> opposed to the idea, but I seem to be in the minority (at least out of
>>> those who spoke up).
>>>
>>> - Jonathan M Davis
>>
>> I don't need named arguments either, but I don't think they would hurt
>> if implemented as a purely optional feature.
>
> Since they affect the API, they _do_ hurt. Since then any changes to parameter
> names break code. So, it has a definite affect on code maintainibility even if I
> don't use the feature myself. I also don't want to see them in code. If the
> example above were possible, then someone would use it in their code (even if
> I didn't), and I'd have to deal with all of the code readibility issues that
> it causes. Named arguments _would_ hurt the language even if they were purely
> optional.
>
> - Jonathan M Davis

That is not what I'd call purely optional.

Timon Gehr wrote:
> That assumes every parameter is implicitly named. If named arguments ever get
> into the language, then they should imho be marked as named arguments explicitly
> at function declaration point.




More information about the Digitalmars-d mailing list