A nice way to step into 2012

so so at so.so
Wed Dec 28 14:34:57 PST 2011


On Wed, 28 Dec 2011 22:57:32 +0200, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

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

Are you aware all the points you made support the need for named arguments  
rather than what you were trying to achieve?
Named parameter fixed a bug in your code and you are trying to explain how  
crap a feature is NP? :)

If you are "trying" to read a function call when it uses named parameters,  
its not the fault of the feature but its implementation in given language.
For this reason i kept saying we shouldn't inherit it from other languages  
but keep it simple.
The feature supposed to ease the reading of a function call and enforce  
some guarantees.

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

It doesn't create readability issues, it is there to solve them.
Maintainability issues? How?
If you change "anything" in your interface, it is already a breaking  
change.


More information about the Digitalmars-d mailing list