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

The compiler is welcome to combine my flags :) I don't prefer using
bitfield flags. Otherwise all the code has to write if(flags &
widget::log_on), seems worse than if(log) ?


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


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

I would be interested to see how a C++ designated initializer with a
struct could work, if you have a link for me.


Related, passing a struct is Microsoft D3D style, eg
CreateDepthStencilState() that also works, but means function calls
needs a struct before it.

https://docs.microsoft.com/en-gb/windows/win32/api/d3d11/nf-d3d11-id3d11device-createdepthstencilstate



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

Would be nice if compilers could warn when header parameter names
mismatch the implementation cpp files.

> 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 feel I already do such changes, a lot of search and replace required
in programming. Quick review of the changes, build, testcases and commit.

Anyone can still call widget.do_something(false) without using the name.
  This only impacts people who wish to use the name (me!)


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

Well, people wouldn't be forced to use the 'parameter: false' syntax if
they didn't want to at least.

Jonny