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@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> 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