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@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals