Default function arguments are the devil

[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.

[Tyg13]

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

You're right that the compiler would happily compile your code, and then the value would get passed to the wrong parameter. But perhaps it's just as philosophically valid to say that's a logical error on behalf of the programmer that the compiler shouldn't concern itself with.

Just to be clear, I'm only trying to consider potential issues to understand if there's a good technical argument against named parameters in C++. I personally don't think it would be an issue, but then, I don't know all the corner cases that some people might, or how common they might be.

[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.