DIP 1030--Named Arguments--Community Review Round 1 Discussion

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed Feb 12 05:03:49 UTC 2020


On Friday, February 7, 2020 8:57:56 PM MST Walter Bright via Digitalmars-d 
wrote:
> On 2/6/2020 7:33 PM, Jonathan M Davis wrote:
> > Well, I'll say again that I don't like the idea of having named
> > arguments in the language, because it makes the parameter names part of
> > the API, resulting in yet more bikeshedding and yet another thing that
> > can't be changed without breaking existing code. Once in a while, named
> > arguments may be useful, but for the most part, they're useful because
> > a function has way too many parameters, in which case, the function
> > should have been designed differently.
> >
> > Unfortunately, since it's Walter who created the DIP, and a number of
> > people do like the idea of named arguments, I expect that some form of
> > this will make it in, but I still think that it's a bad idea.
>
> I appreciate your thoughts on this. But I like the feature even if all it
> does is make the "Flag" template obsolete:
>
>    https://dlang.org/library/std/typecons/flag.html
>
> So instead of:
>
>    foo(Yes.caseSensitive)
>
> we'd write:
>
>    foo(caseSensitive : true)
>
> There's no overhead or cognitive load of an extra type, and it doesn't
> look stupid.

That is an upside to it, though I don't think that it's worth having to deal
with named arguments in general just get rid of Flag. I confess though that
I've always thought that Flag was an unnecessary complication and have only
used it because people have been insisting that it's best practice. I never
use it in code that isn't in a library that I'm writing for other people to
use. If you're familiar with the function, then a naked bool is enough to
understand what the function call is doing and no sort of argument name at
the call site is necessary. If you aren't familiar with the function, then
you should be reading its documentation anyway instead of assuming that you
understand what it does based simply on what it's called or what the names
of its arguments are. And in that sense, named arguments seem to me like a
further excuse to try to claim that you don't need to actually read the
documentation to understand what functions do, which ultimately leads to
shooting yourself in the foot when you make an assumption that doesn't match
the assumptions that the function's author made.

- Jonathan M Davis





More information about the Digitalmars-d mailing list