Abolish the term "converting constructor"

[t3nsor]

The standard defines the term "converting constructor" to mean any non-explicit constructor, while the C++ community generally uses "converting constructor" to mean a non-explicit constructor that takes a single argument that is not a copy or move constructor. This discrepancy is unfortunate. Therefore I propose to replace all uses of "converting constructor" in the standard by "non-explicit constructor".

PR: #6743

[Eisenwave]

I don't really see the benefit tbh. The term "converting constructor" is already in use and referenced in a number of places and you would invalidate all those uses of that term. Stack Overflow has 684 posts using it.

It's not ambiguous, outdated, or otherwise harmful, so I would prefer to keep it. If people say non-explicit, that's also fine. It's okay to have synonyms.

[t3nsor]

I think you missed the point. When people on Stack Overflow or in the broader C++ community use the term "converting constructor", the vast majority of the time, the definition they are using is different from the definition in the standard. So, in fact, if we remove the term from the standard, then the existing uses will become more correct.

[Eisenwave]

The existing uses will become infinitely less correct because they will use dead language that doesn't exist in the standard at all.

This is similar to the purge of POD. If you asked a fresh C++20 user what a POD is, they'd also shrug their arms. It's only going to get less likely that people recognize that term as it gets older. POD may have been a fancy and non-descriptive name that surely annoyed some people, but it didn't get purged just because of that. There was practical motivation, such as splitting it up into multiple finer requirements.

Let's not ignore the fact that you're proposing to purge an established, 20-year old term out of a sudden. Being vaguely annoyed at people using the term imprecisely is not strong motivation to do it. There is no practical purpose to this suggestion, and unlike for POD, there is no plan to deprecate it and phase it out over time. You're just asking for an instant purge.

[t3nsor]

Not all terms that are used by the C++ community have to have a definition in the C++ standard. Some of them arise organically within the community.

In the case of "converting constructor" we do not have a single definition for a term that then gets used "imprecisely". We have two different definitions for the same term: one that is found in the standard and that no one uses, and another one that everyone uses that is not in the standard. The definition in the standard has been there since C++98 but there does not seem to be any convergence within the C++ community toward using the definition in the standard. The reason for this is that the definition in the standard is simply not useful.

The existence of two definitions of the same term, where the one that is never used still appears to be the "official" one because it is found in the standard, makes it more difficult to communicate: every time the term is used in its unofficial sense, it may be labelled as not being "technically correct".

[Eisenwave]

It's not the responsibility of, or within the power of the C++ standard to fix all misconceptions the community has.

The C++ community also uses non-language like "member variable" or "method" despite no mentions of it in the C++ standard. It's not really harmful either: the community knows what people mean by "member variable" and also knows what people mean by "converting constructor". Or, in the context of implicit conversions, the distinction between the standard term and the intuitive term is often not relevant.

The C++ standard is ultimately written for implementers. It's not a tutorial and it's not a community guide. For implementers, the term "converting constructor" is a non-issue. It is not ambiguous, too coarse, or has any other problems that necessitate its purge.

[Eisenwave]

FWIW I like "non-explicit" better, and in an ideal world, it would replace "converting". I just don't see the strong motivation to actually change things given the well-established, unambiguous status quo.