<span> does not have standard layout

[ned14]

I appreciate that <span> is not required to have standard layout, however every other <span> implementation does have standard layout: libstdc++'s, libc++'s, and all the third party library implementations that I am aware of. Except for Microsoft's.

I assume that as usual the ABI ship has sailed, so this will be a wontfix. However, fixing this would be great. Lots of code passes spans to non-C++ code, and not having avoidable UB here would be nice.

[miscco]

@ned14 Are you referring to the empty base class optimization that is applied to span?

[AdamBucior]

I assume that as usual the ABI ship has sailed, so this will be a wontfix.

c++latest has unstable ABI

[miscco]

As I am the culprit here my 2 cents:

Generally I would always prefer composition over inheritance. However, as far as I understand [[no_unique_address]] is currently not supported by MSVC, which is why we went with inheritance.

I do not know whether we could change it given that clang supports it. If the maintainers are ok with [[no_unique_address]] I am happy to provide a patch for that.

[ned14]

@miscco I upgraded MSVC, tried compiling my code, and static asserts about loss of standard layout fired everywhere. The cause was that the code detected that MSVC now provides span<T>, and thus used it for the first time.

Re no unique address for span<T>, I assume that such an optimisation would only make sense if the span's size is consteval known, and thus storage for the span could be completely eliminated entirely. I'll be blunt in saying that I don't, personally speaking, see much use for such an optimisation as span's tend to occupy ephemeral storage which the compiler can as-if eliminate storage in any case.

Me personally, though perhaps you should bring in advice from the Microsoft people first, I'd choose C compatibility over a future ABI break caused by MSVC implementing no unique address on the basis that no unique address optimisation for spans really would be very very rarely useful - only where people store spans in long term storage where lifetime escapes analysis, and they have compile-time known lengths. I know I've never written code like that, and if I did, I'd use std::array like any other sane person. But that's my personal opinon only.

[miscco]

Could you check with a different standard library? As far as I can see both libstdc++ (via [[no_unique_address]]) and libc++ (via a specialization without the _Size data member) implement the same empty base class optimization as we do.

Also I can see some use cases of static size spans, e.g. for sliding windows over data etc.

[ned14]

Could you check with a different standard library? As far as I can see both libstdc++ (via [[no_unique_address]]) and libc++ (via a specialization without the _Size data member) implement the same empty base class optimization as we do.

We were already up on libc++ and libstdc++ in C++ 20, and were using their span<T> implementations if C++ 20 is available. In fact, they had quality of implementation problems which we reported (for reference, yours was fine, worked first time, apart from standard layout).

[CaseyCarter]

Lots of code passes spans to non-C++ code, and not having avoidable UB here would be nice.

Could you clarify this statement? Your request is light on technical details. What code do you believe has defined behavior only with a standard-layout span?

[cbezault]

I think the point here is that passing an object to some C code (or whatever other language) is only well defined if the object has standard layout. Presumably @ned14 is doing that with spans.

[sylveon]

That depends on the internal layout of the span, which is a less than stellar idea.

[cbezault]

Agreed, and ned mentions as much.

I appreciate that is not required to have standard layout, however every other implementation does have standard layout: libstdc++'s, libc++'s, and all the third party library implementations that I am aware of. Except for Microsoft's.

In general, however, I don't actually see a problem in attempting to make classes have standard layout if there's no reason to not have standard layout. (Please correct me if I'm wrong)

Edit: That's not to say I'm in favor of bending over backwards to support something which isn't in the standard. Just if it's easy and there's no downside, why not?

[ned14]

Most of the span implementations use a pointer and a size. The technique I used in Outcome to preserve standard layout was something like:

template<class T, bool pointer_is_consteval, bool size_is_consteval>
struct span_storage
{
  T *_ptr{nullptr};
  size_t _length{0};
};
template<class T, bool pointer_is_consteval>
struct span_storage<T, pointer_is_consteval, true>
{
  T *_ptr{nullptr};
};
template<class T>
struct [[no_unique_address]] span_storage<T, true, true>
{
};

template<class T>
struct span : span_storage ...

So, basically, keep all your member variables inside a single class within the inheritance hierarchy, and standard layout is preserved. Composing member variables by inheritance is what removes standard layout.

[AdamBucior]

Could you give some example of code that needs span to be standard layout?

[miscco]

Ah now I see, https://en.cppreference.com/w/cpp/named_req/StandardLayoutType

We have our members defined in two classes, _Span_extent and span itself.

I have prepared a PR #877 to move to compostition. However, I am unsure if this can be merged before [[no_unique_address]] is available in MSVC