STL icon indicating copy to clipboard operation
STL copied to clipboard

P3016R6 Resolve Inconsistencies In `begin`/`end` For `valarray` And Braced Initializer Lists

Open StephanTLavavej opened this issue 1 month ago • 4 comments

WG21-P3016R6 Resolve Inconsistencies In begin/end For valarray And Braced Initializer Lists

Feature-test macros (expected):

#define __cpp_lib_initializer_list 202511L
#define __cpp_lib_valarray         202511L

I've marked this as Available as it appears we'll want to implement this unconditionally.

StephanTLavavej avatar Nov 10 '25 22:11 StephanTLavavej

Hi all, I’ve been thinking about contributing to the STL recently, and this issue looks like a small, self-contained change I could start with. Much of my early C++ education has come from exploring the MSVC STL source, so it would mean a lot to give something back.

Would it be okay if I worked on this issue?

If yes, I think the required changes given by the wording in section 4 of P3016R6 are quite straightforward; however, I have a few questions and comments:

  • Resolving LWG3624 (section 4.1, i.e., adding #includes of <initializer_list> and/or <typeinfo> to <any>, <functional>, <type_index> and <iterator>) seems quite unrelated to the rest of the paper (update of member functions). Should I include both groups of changes in the same commit/PR or separate them?
  • I tried to familiarize myself with the test suite, but I am not sure how to test for compilation failure (the paper requires that std::begin({1,2,3}) no longer compiles). Could you point me to some docs/other test I could get inspiration from?
  • The nested typedef std::valarray::(const_)iterator is unspecified in the paper. I assume I can keep it as (const) _Ty*, right?

vmichal avatar Nov 12 '25 02:11 vmichal

  • Resolving LWG3624 (section 4.1, i.e., adding #includes of <initializer_list> and/or <typeinfo> to <any>, <functional>, <type_index> and <iterator>) seems quite unrelated to the rest of the paper (update of member functions). Should I include both groups of changes in the same commit/PR or separate them?

This STL already have these #includes (sometimes <initializer_list> is included transitively), so there's no need to do anything.

cpplearner avatar Nov 12 '25 02:11 cpplearner

  • I tried to familiarize myself with the test suite, but I am not sure how to test for compilation failure (the paper requires that std::begin({1,2,3}) no longer compiles). Could you point me to some docs/other test I could get inspiration from?

I guess you can use something like the following. The call to begin is ambiguous before the change.

namespace my {
    template <class T>
    void begin(std::initializer_list<T>);
}

namespace test {
    using std::begin;
    using my::begin;
    static_assert(std::is_same_v<decltype(begin({1, 2, 3})), void>, "");
}
  • The nested typedef std::valarray::(const_)iterator is unspecified in the paper. I assume I can keep it as (const) _Ty*, right?

Yes. I think the intent is to keep the real iterators type unchanged.

frederick-vs-ja avatar Nov 12 '25 05:11 frederick-vs-ja

Thank you for suggestions, I have put the patch together and opened a PR. I have a few comments regarding the resolution of this issue, but I will list them in the PR discussion.

vmichal avatar Nov 12 '25 14:11 vmichal