P2447R4
std::span over an initializer list

1. Changelog

• R4 (pre-Varna 2023):

  • Reorganize references to [P2752] and fix HTML goofs in proposed wording.

• 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. 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?

3.3.1. Better performance via synergy with P2752

[P2752], sent to EWG for Varna, proposes to let a constant initializer_list like {1,2,3} refer to a backing array in static storage, rather than forcing all backing arrays onto the stack. This doesn’t change anything dangling-wise: referring to the backing array of an initializer_list outside that initializer_list's lifetime remains undefined behavior.

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

Today, {{1,2,3}} converts to span by materializing a temporary 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 on the stack. P2752 proposes to performance-optimize the latter (let the backing array occupy static storage) but not the former (keep the status quo for materialized array temporaries). In other words, the initializer_list constructor we propose here in P2447 is "more optimizer-friendly" than today’s array-temporary constructor.

This example (Godbolt) shows how P2447 lets us benefit from P2752’s optimization:

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

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

In each row, there’s no performance difference between the single-braced or double-braced form. But the only way to reach the bottom row (tail-call, no stack usage) is to adopt both P2447 and P2752; which by a happy coincidence also permits the single-braced form.

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<value_type> 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<value_type> 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.