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.