cplusplus / cplusplus/draft

[class.copy.ctor] p15 Only the corresponding active object can be created and copied from the source

Open
#5,193 22 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TeX
Stars
221
Forks
813
Avg merge
16h 4m
Merged PRs (30d)
36

Description

[class.copy.ctor] p15 says

The implicitly-defined copy/move constructor for a union X copies the object representation ([basic.types]) of X. For each object nested within ([intro.object]) the object that is the source of the copy, a corresponding object o nested within the destination is identified (if the object is a subobject) or created (otherwise), and the lifetime of o begins before the copy is performed.

However, [class.union.general] p2 says

In a union, a non-static data member is active if its name refers to an object whose lifetime has begun and has not ended ([basic.life]). At most one of the non-static data members of an object of union type can be active at any time, that is, the value of at most one of the non-static data members can be stored in a union at any time.

It doesn't make sense that we identify or create the corresponding object o for each object nested within the object. Since [basic.life] p1 says such an initialization will begin the lifetime of that object. If we copy each object into the destination, it will make no sense. Consider this example

union U{
  int i;
  char c;
};
U u;
u.i = 0;  // begin the lifetime of the object corresponding to NSDM `U::i`, such that is active
U u2 = u;  // #1

I think the copy initialization at #1 just needs to create the object that corresponds to U::i into u2 and copy the data from u.i. So, is the following phrase the intent of [class.copy.ctor] p15?

The implicitly-defined copy/move constructor for a union X copies the object representation ([basic.types]) of X. For the object to which the active non-static data member corresponds in the source of the copy, a corresponding object o nested within the destination is identified (if the object is a subobject) or created (otherwise), and the lifetime of o begins before the copy is performed.

The similar issue is also in [class.copy.assign]p13.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read [class.copy.ctor] p15 and [class.union.general] p2 together, using the union example in the issue as the starting point. Compare the parallel wording in [class.copy.assign] p13 and follow the discussion to determine whether the copy wording needs clarification. Done means the committee agrees on consistent wording for the active object and its corresponding destination object.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, tex
Domain
documentation
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.