DIP 1019--Named Arguments Lite--Community Review Round 1
Rubn
where at is.this
Fri Mar 1 00:49:25 UTC 2019
On Wednesday, 27 February 2019 at 02:17:30 UTC, Jonathan M Davis
wrote:
> On Friday, February 15, 2019 5:56:45 AM MST Mike Parker via
> Digitalmars-d wrote:
>> This is the feedback thread for the first round of Community
>> Review for DIP 1019, "Named Arguments Lite":
>>
>> https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa 6/DIPs/DIP1019.md
>>
>> All review-related feedback on and discussion of the DIP
>> should occur in this thread. The review period will end at
>> 11:59 PM ET on March 1, or when I make a post declaring it
>> complete.
>>
>> At the end of Round 1, if further review is deemed necessary,
>> the DIP will be scheduled for another round of Community
>> Review. Otherwise, it will be queued for the Final Review and
>> Formal Assessment by the language maintainers.
>>
>> Please familiarize yourself with the documentation for the
>> Community Review before participating.
>>
>> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>>
>> Thanks in advance to all who participate.
>
> I do approve of the fact that this DIP doesn't automatically
> enable named arguments everywhere, since I really, really,
> really don't want to have parameters be part of the API if I
> can possibly avoid it, and I would never use @named anywhere if
> this DIP gets approved - though in all likelihood, that will
> result in arguments about whether folks should slap @named on
> functions or not between folks who want named arguments and
> those who don't. So, approval of the DIP with such an attribute
> could become pretty divisive with regards to how folks write
> libraries.
I don't agree with this at all. The feature becomes all but
useless, it's either all in or just don't include it. So many
things are already part of the API, and this will be an opt-in
feature for the user (not the library developer). The user can
choose to use the variable names if they want, knowing full well
if the author pleases they can change it, but this will be no
different than changing the variable name of struct.
More information about the Digitalmars-d
mailing list