Search Advanced search

Subject: Re: [std-proposals] Making parameter names clearer than func(true, false);

From: Manuel Bergler (berglerma_at_[hidden])

Date: 2019-07-06 11:43:02

Am Sa., 6. Juli 2019 um 18:36 Uhr schrieb Jonny Grant via

Std-Proposals <std-proposals_at_[hidden]>:

>

>

>

> 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.



Pretty much every function taking a boolean (or any fundamental type

for that matter) is lazy API design. In your example you could've also

used two separate scoped enums - one for debugging and one for logging

- instead of adding boolean constants into a namespace. That way the

API enforces readable code at every call site. That doesn't solve

optional parameters though.



>

> 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

> --

> Std-Proposals mailing list

> Std-Proposals_at_[hidden]

> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups