DIP 1019--Named Arguments Lite--Community Review Round 1

[aliak]

On Saturday, 16 February 2019 at 10:02:02 UTC, Francesco Mecca 
wrote:
> On Friday, 15 February 2019 at 17:43:52 UTC, 12345swordy wrote:
>> On Friday, 15 February 2019 at 17:38:23 UTC, Francesco Mecca 
>> wrote:
>>> On Friday, 15 February 2019 at 13:49:04 UTC, Atila Neves 
>>> wrote:
>>>> [...]
>>>
>>> I think that the solution proposed by Atila is better for the 
>>> following reasons:
>>> 1. it is a library solution
>>> 2. allows both the user and the author of a library to 
>>> specify functions with named parameters
>>> 3. it is very lightweight
>>>
>>> [...]
>>
>> You miss the other reason on why it is not enough: Compile 
>> time and run-time performance penalty.
>> -Alex
>
> I have messed with kwargs and compile time doesn't seem to be 
> an issue. At least it is not noticeable to me and I have a 
> quite old dual core cpu.
>
> What kind of runtime penalty do you incur when using the 
> library?
> To me it seems that the only penalty would be error messages.
> Also, kwargs allows unordered arguments and that is the path of 
> lowest friction for people coming from languages with named 
> parameters function (python on top of my mind).
> It makes sense if you want to improve readibility.

kwargs is not scalable. You can't use the same types as 
parameters and you have to create a new type for each parameter. 
It's cumbersome and clunky and it relies on (unenforceable) 
convention to make the call site more readable. And it doesn't 
allow the API author to dictate how their function should be 
called.

Named arguments is not a necessary feature of a language at all, 
it's only useful for maintenance and readability. There're no 
technical advantages to the api author, only psychological and 
aesthetic advantages to the api user, and the many code reviewers 
and maintainers who will follow them.

Ok there is one technical advantage when it comes to overloads 
(See a post above). Maybe there're more ... 🤔🤷‍♂️

Cheers,
- Ali