Skip to content

[array.zero] Fix triple comparison and improve wording consistency #6807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

[array.zero] Fix triple comparison and improve wording consistency #6807

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
463fdac
[array.zero] fix triple comparison and improve wording consistency
Eisenwave Feb 15, 2024
2c83cb7
Update source/containers.tex
Eisenwave Feb 15, 2024
0827797
Update source/containers.tex
Eisenwave Feb 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 7 additions & 8 deletions source/containers.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6395,18 +6395,17 @@

\indextext{\idxcode{array}!zero sized}%
\pnum
\tcode{array} shall provide support for the special case \tcode{N == 0}.
In the case that \tcode{N} equals \tcode{0},
\tcode{begin()} equals \tcode{end()} and
the return value of \tcode{data()} is unspecified.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a normative change, not editorial, as it gives up the requirement that different empty array objects return iterators with a different value. That point may be deemed moot as it is observed only by comparing pointers from different ranges.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could observe a difference if the iterator was of pointer type and std::less compared iterators from two empty arrays. The intent of the current wording seems to be that the iterators from two separate arrays cannot be equivalent according to the total ordering of pointers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent of the current wording seems to be that the iterators from two separate arrays cannot be equivalent according to the total ordering of pointers.

My reading is that this paragraph intended to guarantee that

  • an iterator obtained from array<T, 0> object and a value-initialized iterator never compare equal; and
  • two iterators obtained from two different array<T, 0> objects never compare equal.

And without such guarantees the comparison has (or can have, as decided by the library implementation) undefined behavior ([iterator.concept.forward]/2, [forward.iterators]/2).

However, it is not clear whether the requirement on unique value overrides the specification for forward iterators, and implementations now consistently return value-intialized iterators (libc++ was an exception and conformed to such guarantees, but is not now). I think we should open an LWG issue to drop "unique value".


\pnum
In the case that \tcode{N == 0}, \tcode{begin() == end() ==} unique value.
The return value of \tcode{data()} is unspecified.
In the case that \tcode{N} equals \tcode{0},
the effect of calling \tcode{front()} or \tcode{back()} is undefined.

\pnum
The effect of calling \tcode{front()} or \tcode{back()} for a zero-sized array is
undefined.

\pnum
Member function \tcode{swap()} shall have a
In the case that \tcode{N} equals \tcode{0},
the member function \tcode{swap} has a
non-throwing exception specification.

\rSec3[array.creation]{Array creation functions}
Expand Down