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

[12345swordy]

On Tuesday, 10 September 2019 at 18:11:58 UTC, 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.
>
>
>> 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

*they should mark their function as "@unnamed"

sorry mentally exhausted.