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.

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.

On Sat, 6 Jul 2019, 16:52 Charles Milette via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> This can also be helpful if there's multiple optional parameters but you
> only want to change 1 of them, so you don't have to rewrite all the
> optional parameters that came before.
>
> Since templates also allow optional arguments, is there a possibility of
> adding it there too?
>
> On Sat, Jul 6, 2019, 11:28 Jonny Grant via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> On 06/07/2019 16:05, Arthur O'Dwyer wrote:
>>
>> On Sat, Jul 6, 2019 at 9:13 AM Jonny Grant via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Hello
>>> My first post!
>>>
>>> *Parameter Names*
>>>
>>> Don't you just hate it when you're reading code that looks like this and
>>> no idea what those parameters are ?
>>>
>>> func(true, false);
>>>
>>> This is the function declaration - but it's a pain to go and find that:
>>> void func(bool debug, bool log);
>>>
>>> With this proposal, allowing inclusion of the parameter names makes it
>>> clear:
>>> func(debug=true, log=false);
>>>
>>
>> Well, that's not much of a "proposal" at this stage. ;)
>> Think about what your proposal should do with
>>
>> void func(int debug, int log);
>> int main() {
>> bool debug = false;
>> func(debug=true, log=false);
>> }
>>
>> Yes, assignment would no longer be possible. Maybe better to find another
>> way to write to that doesn't reuse =
>>
>> I had thought to write as debug::true, buy maybe as per the proposal by
>> Axel Naumann a single colon is better, ie debug:true
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0671r2.html
>>
>>
>> And think about what your proposal should do with
>>
>> void func(int debug, int log); // overloaded
>> void func(bool log2, bool debug2); // overloaded
>> int main() {
>> func(debug=true, log=false);
>> }
>>
>>
>> Any exact match of the parameter names should take precedence? If they
>> can be implicitly converted. log=true is an exact match on the param name,
>> and can be implicitly converted.
>> Looks like this is an exact match of "debug" and "log" on void func(int
>> debug, int log); // overloaded
>>
>> So looks like I am supporting Axel's proposal :)
>>
>> cheers, Jonny
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>