[namespace.udecl] Demote normative duplication to notes #1976
Conversation
tkoeppe
added
the
after-motions
source/declarations.tex
Outdated
| This has no effect on the type of the function, and in all other | ||
| respects the function remains a member of the base class. | ||
| Likewise, constructors that are introduced by a \grammarterm{using-declaration} | ||
| A member of a derived class is sometimes preferred to a member of a base class | ||
| if they would otherwise be ambiguous\iref{over.match.best}. |
There was a problem hiding this comment.
This actually only applies to the constructor case, right? (That is, what's now the next paragraph.)
There was a problem hiding this comment.
I'm not sure. With using-declarations and multiple inheritance etc., maybe member name lookup can yield a lookup set that contains both members of a derived class and of a base class (if name lookup could find the members of the base class via some other path). In that case, that note would also apply in that overload resolution gets to choose a unique result.
There was a problem hiding this comment.
The above "In particular, the implicit object parameter is treated as if it were a reference to the derived class" suggests that we don't take derived-to-base conversions on the implied object parameter into account. And actually, I'm not seeing anywhere in [over.match.funcs] that makes this clear; we are just told "X is the class of which the function is a member". So I think that part here is not duplicating other normative wording either.
So I'm not sure there's really all that much normative duplication here.
There was a problem hiding this comment.
@zygoloid, we have in p4 in [over.match.funcs] "For non-conversion functions introduced by a using-declaration into a derived class, the function is considered to be a member of the derived class for the purpose of defining the type of the implicit object parameter." What's missing in that sentence that would be added by a normative "In particular ..." sentence?
|
The mix of normative and non-normative rules here is really strange (your changes here bring that pre-existing strangeness into focus). I think I'd like it more if we added a normative rule to [over.match.funcs] for the inherited constructor case (copying the rule from here) and turned everything in this section into a note. |
|
@zygoloid: If we want to do this properly, we'd need a half-sentence (or so) in each of the three 16.3.1.x subclauses where constructors are enumerated, also in [class.qual] (we could have a using-declaration pointing to a constructor introduced by a using-declaration, recursively). Maybe something like ", including constructors introduced by a using-declaration [namespace.udecl]" or ", including inherited constructors [namespace.udecl]" is good enough. What do you think? |
tkoeppe
removed
the
after-motions
jensmaurer
added
the
decision-required
| If such a constructor is selected to perform the initialization | ||
| of an object of class type, all subobjects other than the base class | ||
| from which the constructor originated | ||
| are implicitly initialized\iref{class.inhctor.init}. | ||
| \begin{note} | ||
| A member of a derived class is sometimes preferred to a member of a base class |
There was a problem hiding this comment.
Editorial meeting consensus: Do not move this note, change "member" to "constructor".
jensmaurer
removed
the
decision-required
The effects of using-declarations naming member functions are discussed in other parts of the standard. The effects of initializing with an inherited constructor are discussed elsewhere, too.
The effects of using-declarations naming member functions
are discussed in other parts of the standard.
The effects of initializing with an inherited constructor are
discussed elsewhere, too.
Fixes #1975.