P3016R6 Resolve inconsistencies in begin/end for valarray and braced initializer lists #8544

AlisdairM · 2025-11-17T07:30:59Z

eisenwave

Some discrepancies.

Especially make sure that the noexcept(noexcept(...)) contents are correct.

eisenwave · 2025-11-17T14:42:08Z

source/support.tex

-#define @\defnlibxname{cpp_lib_apply}@                             202506L // freestanding, also in \libheader{tuple}, \libheader{type_traits}
+#define @\defnlibxname{cpp_lib_apply}@                             202506L
+  // freestanding, also in \libheader{tuple}, \libheader{type_traits}


I don't see this in the paper, so it should presumably done in a different PR because it's totally unrelated.

This entry is merely reformatted. I think such change isn't necessary for CI (otherwise, CI should have been failing before) and should be dropped.

The reformatting avoids splitting <type_- and traits> across two lines, which is an improvement. But it should be a separate commit.

I have amended the original commit and cherry-picked everything else that followed.

source/numerics.tex

eisenwave · 2025-11-17T14:48:00Z

source/numerics.tex

-\indexlibrarymember{begin}{valarray}%
+\indexlibrarymember{valarray}{begin}%


The old way was correct, the way it's described in our specification style guidelines.

Embarrassing -- that was my convention!

eisenwave · 2025-11-17T14:48:32Z

source/numerics.tex

-\indexlibrarymember{end}{valarray}%
+\indexlibrarymember{valarray}{end}%


Same here, the old style was correct.

Still embarrassing -- that was my convention!

eisenwave · 2025-11-17T14:50:53Z

source/support.tex

+    constexpr const E* data() const noexcept;
    constexpr size_t size() const noexcept;     // number of elements
+    constexpr bool empty() const noexcept;
    constexpr const E* begin() const noexcept;  // first element
    constexpr const E* end() const noexcept;    // one past the last element


While the paper doesn't propose any comments in this area, it's inconsistent to have "tutorial comments" on only some of these functions within this block. Maybe a follow-up commit (possibly on a separate PR) could just remove all of those.

I don't think we need code comments like // number of elements telling us that size() returns the number of elements.

I agree with removing them, but it should definitely be a separate PR not as part of this change.

Checking: our preferred resolution is the let the inconsistent lack of comments stand applying the paper, but once it has landed (or before with a rebase?), file a follow-up PR to remove the three one-line comments above?

Yes, apply the paper as-is in this area.

eisenwave · 2025-11-17T14:54:52Z

source/iterators.tex

+  template<class C> constexpr auto
+    begin(C& c) noexcept(noexcept(c.begin())) -> decltype(c.begin());               // freestanding
+  template<class C> constexpr auto
+    begin(const C& c) noexcept(noexcept(c.begin())) -> decltype(c.begin());         // freestanding
+  template<class C> constexpr auto
+    end(C& c) noexcept(noexcept(c.end())) -> decltype(c.end());                     // freestanding
+  template<class C> constexpr auto
+    end(const C& c) noexcept(noexcept(c.end())) -> decltype(c.end());               // freestanding


To be honest, I liked the style in the paper better,
which is

template<class C> constexpr auto begin(C& c) noexcept(noexcept(c.begin())) -> decltype(c.begin());

We usually break after the template-head, and then maybe also break later in the declaration. But I think the <iterator> synopsis is unusual (unique even?) in doing:

template<class C> constexpr auto

i.e. I think it would be move conventional to do:

template<class C> constexpr auto begin(C& c) noexcept(...) -> decltype(...); // freestanding

and if that doesn't fit, then something like:

template<class C> constexpr auto begin(C& c) noexcept(...) -> decltype(...); // freestanding

I like the more conventional style, but deliberately followed the example of breaking already used throughout this clause. Should I apply our more usual breaking pattern to this header as whole, as a distinct commit?

source/iterators.tex

…initializer lists

It is tricky to properly line-break the list of additional headers that contain the range functions, and that list is growing quite large to be displayed as a list in a single sentence. Prefer to render the list as a table instead. Retained the cross-references to the header synopses from the original text, but they look odd in the table format.

Co-authored-by: Jan Schultke <me@eisenwave.net>

AlisdairM mentioned this pull request Nov 17, 2025

[iterator.synopsis] The <iterator> header should be // mostly freestanding #8545

Open

AlisdairM force-pushed the p3016r6_inconsistent_begin_end branch 2 times, most recently from fda8120 to 09fe942 Compare November 17, 2025 08:27

eisenwave added this to the post-2025-11 milestone Nov 17, 2025

eisenwave suggested changes Nov 17, 2025

View reviewed changes

AlisdairM and others added 6 commits November 22, 2025 13:03

P3016R6 Resolve inconsistencies in begin/end for valarray and braced …

3706767

…initializer lists

Update source/iterators.tex

6e8a21a

Co-authored-by: Jan Schultke <me@eisenwave.net>

Update source/iterators.tex

c57c177

Co-authored-by: Jan Schultke <me@eisenwave.net>

Update source/numerics.tex

05d2858

Co-authored-by: Jan Schultke <me@eisenwave.net>

[support.initlist.range] Removed section in xrefdelta.tex

fcda795

AlisdairM force-pushed the p3016r6_inconsistent_begin_end branch from 0834de9 to fcda795 Compare November 22, 2025 06:10

[valarray.range] Correct order of arguments to indexlibrarymember

a373bef

AlisdairM requested review from eisenwave, frederick-vs-ja and jwakely November 22, 2025 06:32

eisenwave approved these changes Nov 22, 2025

View reviewed changes

		\indexlibrarymember{begin}{valarray}%
		\indexlibrarymember{valarray}{begin}%

		\indexlibrarymember{end}{valarray}%
		\indexlibrarymember{valarray}{end}%

P3016R6 Resolve inconsistencies in begin/end for valarray and braced initializer lists #8544

Are you sure you want to change the base?

P3016R6 Resolve inconsistencies in begin/end for valarray and braced initializer lists #8544

Conversation

AlisdairM commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eisenwave left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlisdairM Nov 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

AlisdairM commented Nov 17, 2025 •

edited

Loading

AlisdairM Nov 22, 2025 •

edited

Loading