What's the difference between span and array_view in the gsl library?

Question

In several recent conference presentation I've heard Bjarne Stroustrup and others mention new coding guidelines for C++ and some types supporting them.

Specifically, I remember the example of span<T> instead of (T* p, int n) as a parameter to a function (at time about 32:00 into the talk); but I also remember the suggestion to use array_view<T>. Are they two alternatives but the same concept? Or am I confusing things and they're actually not so related?

I can't seem to find any authoritative definition of what they're both supposed to be about.

Elevator

@DavidHaim: See edit, as well as here for example. – Elevator

There are array view implementations and proposals in the wild. Have you looked at them? – Solubility

I believe that array_view was renamed to span. – Jurdi

@Galik: Can you provide evidence? If you can, write it as an answer and I'll accept... – Elevator

@Yakk: Well, yes, a bit, but I seem to see things which are not necessarily related, like part of Microsoft C++ AMP etc. I figured there might be more than one thing named array_view floating around. – Elevator

@Elevator I added a link to my answer where the renaming was announced – Jurdi

Answer 1

We talked with people in the library working group in the standards committee. They wanted the array_view they are trying to get into the standard to be read only. For the core guidelines, we needed an abstraction that was read and write. To avoid a clash between the (potential) standards and the guidelines support library (GSL), we renamed our (read and write) array_view to span: https://github.com/microsoft/gsl .

Orthotropous

And const array_view<T> plus array view<const T> wasn't satisfactory? – Elevator

Thanks for being committed to the zero cost abstractions mantra - I really do think span would save a lot of programmers from making silly errors. I think communicating these new changes could be done in a clearer way though. I'm just wondering - wouldn't this be something that could be solved as clearly with a regular random access iterator? Was the type added just for clarity? – Exculpate

This was a talk on resources and dangling pointers. span and the GSL was a side issue. Have a look at Neil MacIntosh's CppCon 2015 talk: “Evolving array_view and string_view for safe C++ code" youtube.com/watch?v=C4Z3c4Sv52U and/or have a look at the GSL source: github.com/microsoft/gsl . We are also working on a formal (standard style) specification. – Orthotropous

There was a worry that "view" implied just looking at the contents, not modifying them, so some folks wanted a different suffix for the read/write version. I don't think anyone cares much about a read-only array_view type existing. It's string_view that people care be read-only by default. – Intendment

As a graphics coder where 'view' merely means one's current view into read/write data (e.g. glViewPort, D3D's SetViewport), making "view" read-only is surprising, but outside graphics, I suppose I could see 'view' feeling more like a read-only window than a read/write window. – Dilan

Thankfully the GSL is just GSL and not C++ nor standard whatsoever. – Maladroit

So it is for people that can't handle typing "const" or making a typedef. That's why we need 2 types for an array_view. – Maladroit

Answer 2

In the CppCoreGuidlines The original array_view was renamed to span.

See: https://github.com/isocpp/CppCoreGuidelines/pull/377

It is described thus:

span is a bounds-checked, safe alternative to using pointers to access arrays

Jurdi

I +1'd you, but Bjarne Stroustrup (really?)'s answer is more detailed. – Elevator

@Elevator No, I get it. I'd have probably chosen Bjarne Stroustrup over me too. Not (sniff) taking (sniff) it (sniff) personal (wahhhhhh)... – Jurdi

That comment made me feel something inside, so +1 from me, too ;-) – Punctuality

Answer 3

The document P0122R (2016-02-12) from the Library Evolution Working Group (LEWG)
officially renames the type array_view to span:

Changelog

Changes from R0

• Changed the name of the type being proposed from array_view to span following feedback from LEWG at the Kona meeting.
• [...]

We can also read:

Impact on the Standard

This proposal is a pure library extension. It does not require any changes to standard classes, functions, or headers. It would be enhanced if could depends on the byte type and changes to type aliasing behavior proposed in P0257.

However – if adopted – it may be useful to overload some standard library functions for this new type (an example would be copy()).

span has been implemented in standard C++ (C++11) and is being successfully used within a commercial static analysis tool for C++ code as well as commercial office productivity software. An open source, reference implementation is available at https://github.com/Microsoft/GSL.

In a next chapter, this documents presents the read-only and read-write (mutable) accesses:

Element types and conversions

span must be configured with its element type via the template parameter ValueType, which is required to be a complete object type that is not an abstract class type. span supports either read-only or mutable access to the sequence it encapsulates. To access read-only data, the user can declare a span<const T>, and access to mutable data would use a span<T>.

[...]

---

See also the Guidelines Support Library Review: span<T> from Marius Bancila (march 2016) defining span as:

The Guidelines Support Library is a Microsoft implementation of some of the types and functions described in the C++ Core Guidelines maintained by the Standard C++ Foundation. Among the types provided by the GSL is span<T> formerly known as array_view<T>.

span<T> is a non-owning range of contiguous memory recommended to be used instead of pointers (and size counter) or standard containers (such as std::vector or std::array).

Rehearse