On Sat, 6 Jul 2019, 17:36 Jonny Grant via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

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

Yes it would. Even then, the boolean parameters aren't very descriptive and
this doesn't scale well compared with e.g. flags (I.e. The
ios_base::openmode parameter to the std::ofstream constructor) or settings
structs. However, this mindset is trained on using a language which doesn't
allow named parameters, so there's bias involved.

There are benefits, though. The language is, and has been for some time,
moving towards "say what you mean, not how it should be done".
Encapsulating fundamental types is commonplace and has far reaching
benefits later on, particularly when it comes to extending functionality,
changing to a fast type with a single line change, etc.


> 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);
>

Essentially yes. If the order is arbitrary, (widget::debug_on |
widget::log_off) would make a fine parameter (I'd personally have those as
template parameters, but it's just an example).

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


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

No, this would be an underlying mechanism that would be equivalent, but not
necessarily identical, to passing in a struct instead. There need not be
any change to the developer's approach.

My main concern with the idea is that it "locks in" parameter names for
libraries that might not have prepared for people to actually write
parameter names down. Although it's a good idea to make sure your headers
are tidy and that your parameters are well named *anyway*, that can
sometimes be an afterthought. As fixing typos in parameter names has never
had side effects before, there's going to need to be a fair amount of
forewarning. In a language like C++, some libraries are written with
parameter names that are evidently designed to be useful to the
implementer, not the user. A change means that changes that were not
previously breaking can become breaking.

I certainly wouldn't want to be the guy who has to maintain a library where
people have been writing:

widget.do_something(send_messgae=false)

for a few months and now I'm unable to correct that typo. It'd drive me
crazy.

I'm not hard-line on this, but I still just want to be sure that people are
aware of just how big a change this would be on a conceptual level. The
technical level is a whole other ballgame.