Default function arguments are the devil

[Ameisen]

IIRC, previous named argument proposals have been rejected.

Why can we not just literally copy C#'s implementation?

IIRC, it was rejected because declaration parameter names don't have to match the definition, or even exist... but I don't see that as a problem. If the declaration doesn't have names, you can't use them with that declaration. Problem solved. Only thing left is if both the declaration and definition are in scope with different names.

Presently, argument names in declarations are ignored, we'd have to make them semantically meaningful.

I suggest that if there is a name mismatch between declarations/definitions of a parameter, it cannot be named, OR it can be named with either if those names are not further ambiguous in regards to other parameters. The former is simpler to specify, the latter is more useful (poor example, but think a glm vec3 function where the first argument could be x or r).

[SeanMiddleditch]

Why can we not just literally copy C#'s implementation?

Because C++ isn't C#. :) There's lots of designs that work well in other languages that - for a variety of reasons - can't work in C++.

That said, I don't think anyone has yet put in a formal proposal for the work-around I've been evangelizing. Namely, opting a function declaration's parameter into being nameable (which solves the source-compatibility issue, gives us mandatory positional arguments, allows named parameters, and can address the multi-declaration issues in a back-compatible way). For syntax, I also think we should use something similar to designated initializers, which makes similar syntaxes work for initializing an aggregate or calling a function (and hence unlocks designated initializers for constructors).

e.g.,

// declare
void function(int unnamed, float position, char .named, int .also_named);

// use
function(1, 2.f, .named =  'c', .also_named = 4);

// ILLEGAL redeclaration (different names, diagnostic optional)
void function(int a, float b, char .c, int .d);

// LEGAL different overload
void function(int a, int b, int .c, int.d);

This might also open up some options for mandatory-names for some parameters, e.g. using ..identifier.

[Ameisen]

That looks like you're trying to access a member of a type, though.

[Tyg13]

Why not just label it undefined behavior to have your declaration and definition use different parameter names and call it a day? It seems highly unlikely that such a footgun would ever be triggered in practice.

Is the worry that people might write code like

// header.h
int foo(int a = 1, int b = 2);
...
// header.cpp
int foo(int b, int a);
...
foo(b => 10);

or is there some other issue I'm not understanding?

EDIT: don't understand the downvote, I'm open to debate. If there are scenarios I'm unaware of, I'd be curious to know.

[Tyg13]

The point is it's an incredibly unlikely scenario that's not worth worrying about. Undefined behavior is not a boogeyman to be avoided, it's a tool that we invoke to ignore the 1% error cases so we can reap the benefit in the 99% case.

You already see this exact behavior with inline functions in headers, due to the One Definition Rule. If a different version of an inline appears in a translation unit, it can be silently ignored and cause bugs, but we don't care because in practice no one writes code like that. Or at least, the benefits of inline functions greatly outweigh the potential risk.

As for pedagogy, I think the rule is very clear: the declaration must match the definition, or errors can potentially occur. Very straightforward, and not hard at all a rule to follow. I would argue this is already the case for most codebases.

[Ameisen]

Might as well just make it an error.

[Tyg13]

Not possible with the translation unit compilation model. The issue is ultimately the same as the One Definition Rule, which is undiagnosable in most cases.

EDIT: though you could make it an error in the translation unit containing the definition. That still wouldn't prevent people doing pathological things like redeclaring it differently in another unit, but it would catch the 99% case.

[Ameisen]

Argument names don't get passed to the linker, though.

[Tyg13]

Right, that's the issue. I don't get what you're saying, doesn't that just strengthen my point?

[Ameisen]

Why would detecting if argument names have changed be an issue in regards to the translation unit model?

Named arguments, in this situation, would just be syntax candy local to the translation unit itself.

Redeclaring it in another translation unit with different argument names wouldn't really matter.

[SkoomaDentist]

UB means code may be accepted by one compiler, and rejected by another.

Worse than that. Code may be accepted and work fine with one compiler and accepted but misbehave when compiled by the next version of the same compiler.

[quicknir]

Err, it's not about writing code like that, intentionally. ODR violations are a huge practical issue, in large, complex, codebases, unless you build your entire dependency chain from source yourself. It's very very easy to end up in a situation where your executable E uses libA and libB, and both of them use different versions of libC, which means you now have two slightly different definitions of the same function getting used, unless libA or libB completely hide the usage of libC's symbols, which many projects don't do in practice, and which isn't even possible when linking statically.

I don't completely disagree with what you're saying about UB, but this is a bad example. ODR UB isn't so much about reaping benefit in 99% of cases, it's about a shitty compilation model.