On 06/07/2019 17:17, Jake Arkinstall via Std-Proposals wrote:
> We've had many a discussion on this and it's a bit... fiddly. I still
> hold that with a type interface as good as we have, there's no need for
> named parameters as long as we don't have people going around writing
> functions called "func" that take two booleans.

It would be similar with widget.init(filename, true, false) wouldn't it?

My only workaround for this is for every method to provide in the class
namespace a widget::debug_on etc, so can then call:

widget.init(filename, widget::debug_on, widget::log_off);


> However, that's just my take. There are good examples of where it
> becomes useful, and on the other hand there are examples of where it
> encourages lazy, difficult to optimise API design with bag functions.
> There are questions about mangling (unless you tie it to the header),
> questions about compatibility, questions about collision handling, and
> questions about ordering requirements. I believe the last conversation
> ended with an idea about treating function parameters as a struct with
> defaults and using C++20's designated initializer syntax. Now we know
> designated initializers have made it into the next iteration of the
> language, that approach seems the most promising.

Could you share an example of where it encourages lazy or difficult to
optimize api design please.

C99 has had designated initializers for a long time I recall. How would
this work in C++ for this issue?
Would we need to provide two versions of the same method?

Cheers, Jonny