P2447R3
std::span over an initializer list

1. Changelog

• R3:

  • Changed primary authorship from Federico Kircheis to Arthur O’Dwyer.

  • Removed R2’s feature macro __cpp_lib_span_init; it didn’t seem motivated.

• R2:

  • Discussed in LEWG telecon, 2022-07-26

2. Background

C++17 added string_view as a "view" over constant string data. Its main purpose is as a lightweight drop-in replacement for const string& function parameters.

int take(const std::string& s) {
    return s[0] + s.size();
}

int take(std::string_view sv) {
    return s[0] + s.size();
}

std::string abc = "abc";
take(abc);

std::string abc = "abc";
take(abc);

take("abc");

take("abc");

take(std::string("abc"));

take(std::string("abc"));
take(std::string_view("abc"));

C++20 added span<const T> as a "view" over constant contiguous data of type T (such as arrays and vectors). One of its main purposes (although not its only one) is as a lightweight drop-in replacement for const vector<T>& function parameters.

int take(const std::vector<int>& v) {
    return v[0] + v.size();
}

int take(std::span<const int> v) {
    return v[0] + v.size();
}

std::vector<int> abc = {1,2,3};
take(abc);

std::vector<int> abc = {1,2,3};
take(abc);

take({1,2,3});

take({}); // size=0
take({{1,2,3}});
take(std::vector{1,2,3});
take(std::initializer_list<int>{1,2,3});

take({}); // size=0
take({{1,2,3}});
take(std::vector{1,2,3});
take(std::initializer_list<int>{1,2,3});
take(std::span<const int>({1,2,3}));

This table has a conspicuous gap. The singly-braced initializer list {1,2,3} is implicitly convertible to std::vector<int>, but not to std::span<const int>.

3. Solution

We propose simply that std::span<const T> should be convertible from an appropriate braced-initializer-list. In practice this means adding a constructor from std::initializer_list.

3.1. Implementation experience

This proposal has been implemented in Arthur’s fork of libc++ since October 2021. See "span should have a converting constructor from initializer_list" (2021-10-03) and [Patch].

3.2. What about dangling?

span, like string_view, is specifically designed to bind to rvalues as well as lvalues. This is what lets us write useful code like:

int take(std::string_view s);
std::string give_string();
int x = take(give_string());

int take(std::span<const int> v);
std::vector<int> give_vector();
int x = take(give_vector());

Careless misuse of string_view and span outside a function parameter list can dangle:

std::string_view s = give_string(); // dangles
std::span<const int> v = give_vector(); // dangles

P2447 doesn’t propose to increase the risk in this area; dangling is already likely when span or string_view is carelessly misused. We simply propose to close the ergonomic syntax gap between span and string_view.

std::string_view      s = "abc";  // OK
std::string_view      s = "abc"s; // dangles
std::span<const char> v = "abc";  // OK
std::span<const char> v = "abc"s; // dangles

std::string_view      s = "abc";  // OK
std::string_view      s = "abc"s; // dangles
std::span<const char> v = "abc";  // OK
std::span<const char> v = "abc"s; // dangles

std::span<const int> v = std::vector{1,2,3}; // dangles
auto v = std::span<const int>({1,2,3});      // dangles
std::span<const int> v = {{1,2,3}};          // dangles

std::span<const int> v = std::vector{1,2,3}; // dangles
auto v = std::span<const int>({1,2,3});      // dangles
std::span<const int> v = {{1,2,3}};          // dangles
std::span<const int> v = {1,2,3};            // dangles

3.3. Relation to P2752 Static storage for braced initializers

[P2752R1] (R0) proposes to permit a constant initializer_list like {1,2,3} to refer to a backing array in static storage, rather than forcing all backing arrays onto the stack. At least for now, this doesn’t change anything dangling-wise: referring to the backing array of an initializer_list outside the lifetime of that initializer_list remains undefined behavior.

std::string_view s = "abc";            // OK, no dangling
std::span<const int> v1 = {1,2,3};     // dangles, even after P2752

3.4. Why not just double the braces?

Since we can already write

std::span<const int> v = {{1,2,3}}; // dangles

Well, a single set of braces is good enough for vector, and we want span to be a drop-in replacement for vector in function parameter lists, so we need to support the syntax vector does. There was a period right after C++11 where some people were writing

std::vector<int> v = {{1,2,3}};

So I prefer to turn the question around and say: Since we can already implicitly treat {{1,2,3}} as a span, how could there be any additional harm in treating {1,2,3} as a span?

This also relates to [P2752R1]: Today, {{1,2,3}} converts to span by materializing a temporary of type const int[3] on the stack. Tomorrow, if P2447 is adopted, {1,2,3} will convert to span via an initializer_list that refers to a backing array also allocated on the stack. [P2752R1] proposes to performance-optimize the latter case (permitting the backing array to occupy static storage) but not the former case (keeping the status quo for materialized array temporaries). In other words, tomorrow’s (single-braced or double-braced) initializer_list constructor is "more optimizable" than today’s double-braced array-temporary constructor.

The following program (Godbolt) shows how P2447 lets us benefit from P2752’s optimization:

int perf(std::span<const int>);

int test() {
    return perf({{1,2,3}});
}

4. Annex C examples

This change will, of course, break some code (most of it pathological). We might want to add some of these examples to Annex C.

However, any change to overload sets (particularly the addition of new non-explicit constructors) can break code. For example, there was nothing wrong with C++23’s adopting [P1425] "Iterator-pair constructors for stack and queue" with no change to Annex C, despite its breaking code like this:

void zero(queue<int>);
void zero(pair<int*,int*>);
int a[10];
void test() { zero({a, a+10}); }

We can simply agree that such examples are sufficiently unlikely in practice, and sufficiently easy to fix, that the benefits of the changed overload set outweigh the costs of running into these examples.

4.1. Overload resolution is affected

void one(pair<int, int>);
void one(span<const int>);
void test() { one({1,2}); }

4.2. The initializer_list ctor has high precedence

void two(span<const int, 2>);
void test() { two({{1,2}}); }

4.3. Implicit two-argument construction with a highly convertible value_type

In these two highly contrived examples, the caller deliberately constructs a span via its iterator-pair constructor implicitly, from a braced initializer of two elements, and furthermore value_type is implicitly convertible from the iterator type. These examples strike me as highly contrived: both conditions are unlikely, and their conjunction is unlikelier still.

int three(span<void* const> v) { return v.size(); }
void *a[10];
int x = three({a, 0});

int four(span<const any> v) { return v.size(); }
any a[10];
int y = four({a, a+10});

5. Proposed wording

Modify [span.syn] as follows:

#include <initializer_list>     // see [initializer.list.syn]

Modify [span.overview] as follows:

  template<size_t N>
    constexpr span(type_identity_t<element_type> (&arr)[N]) noexcept;
  template<class T, size_t N>
    constexpr span(array<T, N>& arr) noexcept;
  template<class T, size_t N>
    constexpr span(const array<T, N>& arr) noexcept;
  template<class R>
    constexpr explicit(extent != dynamic_extent) span(R&& r);

  constexpr explicit(extent != dynamic_extent) span(std::initializer_list il) noexcept;
  constexpr span(const span& other) noexcept = default;
  template<class OtherElementType, size_t OtherExtent>
    constexpr explicit(see below) span(const span<OtherElementType, OtherExtent>& s) noexcept;

Modify [span.cons] as follows:

   constexpr explicit(extent != dynamic_extent) span(std::initializer_list il) noexcept;

Constraints: is_const_v<element_type> is true.

Preconditions: If extent is not equal to dynamic_extent, then il.size() is equal to extent.

Effects: Initializes data_ with il.begin() and size_ with il.size().

6. Acknowledgments

• Thanks to Federico Kircheis for writing the first drafts of this paper.