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

[12345swordy]

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.


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

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