On Mon, Jul 8, 2019, 12:09 PM Jonny Grant via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> On 06/07/2019 17:59, Jake Arkinstall via Std-Proposals wrote:
> > On Sat, 6 Jul 2019, 17:36 Jonny Grant via Std-Proposals,
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
>
> > Could you share an example of where it encourages lazy or difficult
> to
> > optimize api design please.
> >
> >
> >
> https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_csv.html#pandas.read_csv
>
> Feels like that could just be a coding standard, training issue. I've
> equally seen functions which are just as unusable
>
> f(false, 0, true, -1, nullptr, false);
>

I find the word choice here really puzzling. Lazy? "Just as unusable"?

The thing is, when you have named parameters, you can just write one
function that takes 30 parameters. And that can be a great API. How many
parameters can maplotlib.pyplot.plot() take? Probably hundreds. And some
parameters even have long and short names (e.g. linewidth and lw)! That's
not lazy and it's certainly not unusable - on the contrary, it's one of the
most usable and useful libraries I've ever used.

It's only lazy in contrast to C++, where in order to make something like
this usable you need to write dozens of functions and probably hundreds of
lines of code. Named parameters just let you... not do that. That's not...
laziness.

The reason we say multi-argument functions are anti-patterns in C++ is
precisely because you cannot possibly get the arguments right. Because you
can't name them.

And like, strong typing (or opaque typedefs) is just not at all a solution
for named parameters. At best, it can give you a very crude approximation
for the simplest possible thing named parameters give you at the cost of a
lot of syntax. There is a problem that strong typing solves... and that
problem is not named parameters. There's nothing wrong with writing
functions that take int or bool.

Barry

>