Date: Sun, 04 Jan 2026 13:40:29 -0300
On Sunday, 4 January 2026 13:11:15 Brasilia Standard Time Jason McKesson via
Std-Proposals wrote:
> Some things on your list don't declare a different entity. Default
> arguments don't make the entity different. But most of the ones on
> your list do denote different entities. If you change a non-template
> function into a template function, that *is* a fundamentally different
> entity. Changing the types of function arguments creates a different
> entity. Etc.
>
> I think it's wrong to consider changes that fundamentally create a
> different kind of entity to be "implementation details". You can think
> of them that way if you like, but as far as the language itself is
> concerned, those are different entities.
Strictly speaking, that's correct.
But in practice many a project relies on the ability to replace one entity
with another (or more than one, or replace multiple with one) while retaining
source-compatibility if not binary compatibility too.
We do in Qt.
> When the writer of a library has written their interface a certain
> way, whether they intended to or not, they have formed a contract
> between themselves and the caller that the interface may not be
> changed in any way that would represent a change in that entity. Or if
> they do change it, this constitutes a breaking change even if nobody
> actually gets broken by it.
And we have quite a few workarounds to that, though by strict interpretation
of the language the majority of them are ODR violations.
> The C++ standard has rules about how standard library interfaces are
> allowed to be written to permit a certain amount of variance in terms
> of implementations (particularly of overload sets). But unless that
> kind of rule is a part of the documentation of the library in
> question, the way you write a function is baked into that interface.
Which is why things need to be documented how they ought to be used, not how
the implementation happens to exist. Depending on implementation details is
not conducive to long-term mental health.
> I'm not familiar with Kotlin, but most of the languages I'm familiar
> with that have named arguments treat them as a fundamental,
> unchangeable property of that entity. As fundamental a property of an
> entity as its parameter list.
That's good, should be what we aim for, and what we would have in a green field
scenario. The problem is that we are not in a green field.
We have existing libraries, many of which use uglified parameter names for
reasons (mostly two I can think of: to avoid clashes with macro and to avoid
identifier-shadowing warnings). It might be possible to fix the implementations
to have clean names, but it's not going to be everywhere nor will it happen
overnight.
We need a transition plan. That may be attributes for the cases where macros
aren't the issue. I don't see how to solve this for macros without imposing
parsing changes to the preprocessor, short of Modules (another thing we have
no transition plan for).
Std-Proposals wrote:
> Some things on your list don't declare a different entity. Default
> arguments don't make the entity different. But most of the ones on
> your list do denote different entities. If you change a non-template
> function into a template function, that *is* a fundamentally different
> entity. Changing the types of function arguments creates a different
> entity. Etc.
>
> I think it's wrong to consider changes that fundamentally create a
> different kind of entity to be "implementation details". You can think
> of them that way if you like, but as far as the language itself is
> concerned, those are different entities.
Strictly speaking, that's correct.
But in practice many a project relies on the ability to replace one entity
with another (or more than one, or replace multiple with one) while retaining
source-compatibility if not binary compatibility too.
We do in Qt.
> When the writer of a library has written their interface a certain
> way, whether they intended to or not, they have formed a contract
> between themselves and the caller that the interface may not be
> changed in any way that would represent a change in that entity. Or if
> they do change it, this constitutes a breaking change even if nobody
> actually gets broken by it.
And we have quite a few workarounds to that, though by strict interpretation
of the language the majority of them are ODR violations.
> The C++ standard has rules about how standard library interfaces are
> allowed to be written to permit a certain amount of variance in terms
> of implementations (particularly of overload sets). But unless that
> kind of rule is a part of the documentation of the library in
> question, the way you write a function is baked into that interface.
Which is why things need to be documented how they ought to be used, not how
the implementation happens to exist. Depending on implementation details is
not conducive to long-term mental health.
> I'm not familiar with Kotlin, but most of the languages I'm familiar
> with that have named arguments treat them as a fundamental,
> unchangeable property of that entity. As fundamental a property of an
> entity as its parameter list.
That's good, should be what we aim for, and what we would have in a green field
scenario. The problem is that we are not in a green field.
We have existing libraries, many of which use uglified parameter names for
reasons (mostly two I can think of: to avoid clashes with macro and to avoid
identifier-shadowing warnings). It might be possible to fix the implementations
to have clean names, but it's not going to be everywhere nor will it happen
overnight.
We need a transition plan. That may be attributes for the cases where macros
aren't the issue. I don't see how to solve this for macros without imposing
parsing changes to the preprocessor, short of Modules (another thing we have
no transition plan for).
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-01-04 16:40:40