[basic.life] Add cross-reference for union member lifetime #5228
Conversation
|
@zygoloid , I think this is right, but I'd appreciate your review. |
|
Usually, when a standard defines a general rule and, in other sections, has rules overriding it for some specific cases, the generic rule does not (normatively) enumerate exceptions. Why [basic.life]/1 shall be an exception? |
Because the general rule uses the wording: only begins, and it also didn't say such as except/unless otherwise specified. In a contrast, [basic.lookup] says
The clause didn't cover the dependent names in a template definition, but it does say: Unless otherwise specified, which means there can exist an exception, in other places, that [basic.lookup] does not explicitly list it. Thus, that general rule should be responsible to enumerate all the cases. |
wg21bot
added
the
needs rebase
jensmaurer
removed
the
needs rebase
| initialized member in the union\iref{dcl.init.aggr,class.base.init}, | ||
| or as described in \ref{class.union} and \ref{class.copy.ctor}, | ||
| or as described in | ||
| \ref{class.union}, \ref{class.copy.ctor}, and \ref{class.copy.assign}, |
There was a problem hiding this comment.
Of these cases, only [class.copy.ctor] (calling a union copy constructor) starts the lifetime of the union member subobject. Both the [class.union] (assigning to a union member) and [class.copy.assign] (assigning to a union) cases create a new object that transparently replaces the union member. So I think only [class.copy.ctor] is in scope here, although the reason for that is subtle.
There was a problem hiding this comment.
I suppose another viewpoint is that, because the newly-created object transparently replaces a union member subobject, it is itself a member subobject ([intro.object]p2), and so it is in the scope of this rule, in which case this change seems appropriate. Either way, we should be consistent: either both [class.union] and [class.copy.assign] should be listed here or neither of them.
Given the existing state of this wording, accepting the proposed change seems reasonable to me.
|
Thank you, @zygoloid! @jensmaurer, I suppose we'll take this as-is then? I'm sure I don't appreciate all the subtleties here, so I'll take your word for it. |
|
@tkoeppe, I think we should take this as-is. |
Fixes #5219