DIP 1020--Named Parameters--Community Review Round 2

rikki cattermole rikki at cattermole.co.nz
Tue Sep 10 18:41:50 UTC 2019


On 11/09/2019 6:11 AM, 12345swordy wrote:
> On Tuesday, 10 September 2019 at 16:09:39 UTC, rikki cattermole wrote:
>> On 11/09/2019 3:45 AM, 12345swordy wrote:
>>> On Tuesday, 10 September 2019 at 14:19:02 UTC, rikki cattermole wrote:
>>>> On 11/09/2019 2:01 AM, 12345swordy wrote:
>>>>> Issues with the "@named" attribute:
>>>>> 1.This is opt-in rather then opt-out, which may causes users to beg 
>>>>> the library maintainers to update their libraries to support name 
>>>>> attribute.
>>>>
>>>> This is intended.
>>>> If you want to override the intention of the API author then we need 
>>>> to find another solution. One which I am unsure about how good it 
>>>> would be.
>>>
>>> Make it an opt-in compiler flag.
>>>
>>> Alex
>>
>> I do not believe a flag like this is a good solution.
>> Over the years there has been a lot of talk about how bad -property is 
>> and it is similar in function to what you are proposing.
> 
> The issue with property atm, is that is half-baked. People keep thinking 
> that optional parentheses will replace it. It didn't as it doesn't 
> support operators such as += and ++. This flag deals with the 
> interaction with other libraries and public interfaces.

I remain against it. However I will think about what you are saying with 
the flag. Even if I think the syntax ``! Identifier :`` to match against 
both named and unnamed parameters would cover you instead better.

>> However I do have a syntax in mind if there is an overwhelming call to 
>> support overriding the API makers intention for an API.
>>
>> The problem with it is, I have no idea how it would be implemented. 
>> But Walter seems to, so if the desire is there by enough people I 
>> guess I would have to add it.
> 
> Would it be better to have the named arguments opt-out via @unnamed 
> instead of opt-in via @named? If certain people are that worry about 
> breaking the public API, they should avoid mark their function as 
> "@unnamed", instead having to mark every function @named just to use 
> named arguments.

Positional should remain the default (otherwise you risk changing how 
existing code gets thought about).

Anyway, I doubt anyone would use such an attribute.

I see named arguments used sparingly when the abstractions need it. I 
would question any code that used named parameters so heavily as to have 
them on every single parameter in quite large files.

> Besides we are dealing with c and c++ external bindings, and there are 
> tools that generate those bindings. If I were to modify the tools to 
> generate the @named arguments automatically, I still may end up in a 
> plausable situation where the c/c++ library managers may changed the 
> arguments names, which then causes breakage in the public api. Which it 
> renders the case for @named moot, as you are not necessarily the 
> developer for those c/c++ libraries.

This DIP does not limit named parameters to extern(D) code. Since there 
may be valid reasons to need to extern(C) it within a code base.

But I do not intend for this feature to be used with other languages. 
Since their API authors you are binding to could not intend for their 
API to work with it.

> This dip fail to provide a solid case where breakage from the change of 
> the public api function arguments is a huge deal that needs to be avoided.
> 
> - Alex

Actually right now I think DIP 1020 has the potential to have breakage 
from the change of API named parameter names. It alone provides no tools 
to deal with it.

Apart from designing a little defensively, I am not taking a stance on 
this problem in the DIP. But I think I should consider what you are 
saying. I think there is something I should take note of here but I'm 
not sure what it is just yet.


More information about the Digitalmars-d mailing list