Hi,

in my code base, I use argument comments, i.e.
  `f(/*isStrict=*/true);
and then use clang-tidy [0] to enforce that the name in the comment matches
the name of the parameter
in the declaration of the function.

I find it very useful, and it is available right now.

[0]
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html

Best regards,
Matthias



Am Mo., 8. Juli 2019 um 14:51 Uhr schrieb Mark A. Gibbs via Std-Proposals <
std-proposals_at_[hidden]>:

> On 2019-07-06 12:59 p.m., Jake Arkinstall wrote:
>
> 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.
>
> If we had named parameters where we could overload on the parameter
> names—which, I would hope, would be part of the package of named
> parameters—wouldn't that be a non-issue?
>
> class widget
> {
>
> // ... stuff ...
>
> // (assuming the !bang is the way to mark
> // a parameter name as part of the interface)
> auto do_something(bool !send_messgae) -> whatever;
>
> // Just add another overload
> auto do_something(bool !send_message)
> {
> return do_something(send_messgae=send_message);
> }
>
> // ... more stuff ...
> };
>
> // At call site, original code still works:
> widget.do_something(send_messgae=false);
>
> // And fixing the typo is a transparent change:
> widget.do_something(send_message=false);
>
> Or, perhaps even better, implement the typoed version in terms of the
> correct version, and mark the typoed version [[deprecated]].
>
> The only "catch" would be if "nameless" calling were still possible,
> because then widget.do_something(true) would become ambiguous. Again,
> that would probably be a non-issue if there were a way to mark a particular
> overload as the "default" when parameter names are not given: you'd simply
> make the new overload the "default".
>
> It might actually be *less* work to fix a typo there than it would if
> you'd used strong typing.
>
> For the record, I prefer strong typing as the solution to this problem. I
> just wish there were an easier way to create strong type aliases. Sutter's
> "metaclasses" may be a solution to that. It occurs to me that named
> parameters could be nothing more than on-the-fly strong typing, where:
>
> auto func(bool !name) -> void;
>
> just translates to something like:
>
> struct __func__name
> {
> explicit __func__name(bool v) : _v{v} {}
>
> // etc.
>
> bool v;
> };
>
> auto func(__func__name __name) -> void;
>
> and permutations with multiple named parameters could be "auto-generated"
> (or, more likely, reordered at the call site).
> Looking at it that way might make named parameters more palatable in the
> C++ ecosystem.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>