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