C++ Logo

std-proposals

Advanced search

Re: Proposal: template function solution to Pythonic optional function arguments

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Mon, 20 Jul 2020 16:43:14 -0400
On Mon, Jul 20, 2020 at 2:23 PM codusnocturnus via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Having the code-bloat associated with defining and naming a struct, as well as pulling in std::optional all over the place to get the equivalent of named parameters is objectively terrible (I think you even questioned the viability), and, subjectively, it looks awful at the call site, too.

Or, you could just not use named arguments. Broadly speaking, named
arguments is only useful when you have a function that takes a lot of
parameters (none of which have any logical grouping between them).
Most functions generally take 5 or less. Named arguments become
increasingly useful the more parameters a function takes.

But if you can avoid having functions take large numbers of parameters
to begin with, then you don't really *need* them.

> It's one thing to jump through hoops on the called side of an API, but forcing the calling side into contrived patterns to achieve what is commonly available in modern languages just seems rude.
>
> Straight-up named parameter calling (not looking for any variadic nonsense à la *args/**kwargs)

That right there is kind of a problem: if you can't forward named
parameters to another function, then you break a lot of very useful
use cases. You can't `emplace`-construct any object with named
parameters, for example.

I would consider that a non-starter for such a feature.

> would make function overloading and default parameters as useable in C++ as they were intended to be. These are features that distinguish C++ from C, but today (on this very thread) we have notable language experts actively campaigning against their use!

We do? I've heard people say that default arguments should be avoided,
but I've *never* heard any "notable language experts" saying that we
should avoid function overloading in general.

Received on 2020-07-20 15:46:50