On Thursday 18 July 2024 09:09:59 GMT-7 Sebastian Wittmeier via Std-Proposals
wrote:
> Trivial lists
>
> pair, span, string_view

Given that std::pair must have a member called "first" and one called "second"
and their initialisation order is defined, they are effectively data-layout-
compatible. Whether they are fully compatible will depend on whether the types
are "trivial for the purposes of function calling" - that is, will they be
passed in registers or not? I don't know if the Standard allows std::pair to
be trivial if the template parameter types are themselves trivial. Even then,
a compiler could force the function-passing ABI to trivial in that case.

Either way, this violates the rule of use of std::pair: NEVER. Therefore, I
don't think we should devote any time to it.

std::span and std::string_view internal layouts are not specified. Therefore,
there are 2*2 possibilities:
a) whether to store length or to store an end pointer
b) whether to store the length/end first or the starting pointer first

Generally speaking, implementations store the length because CPUs have
interesting tricks to perform additions on-the-fly, and size() and empty() are
used more often than end() anyway.

And wouldn't you know it, but libstdc++ and libc++ differ on (b) point for
basic_string_view.
libstdc++:
      size_t _M_len;
      const _CharT* _M_str;
libc++:
  const value_type* __data_;
  size_type __size_;

So this is too late to change now. Maybe for libstdc++.so.7 (QStringView has
the same mistake and we'll fix for Qt 7, along with a mistake in selecting the
bits for tagging in QAnyStringView).

They do agree on std::span with dynamic extents.

> More complex "lists"
>
> string, vector

This is not desired. The maintainers in the three libs have explicitly made
different choices for SSO as well and each of them presumably thinks their
choice is the best (they are three-way incompatible with each other and I'm
not talking about the size of the buffer).

> Units
>
> time_point

This one is compatible by sheer obviousness of the implementation. There isn't
much to differ on anyway.

However, I still need to write the paper to add native_handle() to the clock
types, so different implementations talking to each other on the same system
can agree upon what clock they are talking about. Further, one expects that
libstdc++ and libc++ and MS STL agree upon what clock is what on each of the
platforms (steady_clock in particular).

> Error handling
>
> runtime_error, logic_error, expected

(Note: I think std::bad_alloc and std::bad_cast are in libsupc++ & libcxxabi)

I don't work with exceptions so I personally don't care either way. There
aren't enough hours in the day for me to be bothered on this. It looks like
the types derived from std::exception aren't made to be compatible because the
designers didn't expect that code using a different C++ Standard Library
implementation would have useful information to deal with an exception thrown
from another library. At that point, they probably thought stack unwinding
would suffice because the only thing that one can do is the emergency save.

However, that means one can't design an extern "C" API that throws either.
Anyway, for me that's a feature not a bug.

std::expected I don't have enough experience on yet. It's probably like
basic_string_view: if you can't pass that argument, then there's no point in a
high-level C++ return type either.

> Types like string_view and span are defined simple and clear enough that an
> explicit paper demanding their extraordinary stability is not necessary.
> However, a paper recommending to use those existing types for more ABI
> stability and compatibility is not bad per se.

Except it's not going to be accepted. At this point, it's far more valuable
for libstdc++ to be compatible with previous libstdc++ than to be compatible
with libc++.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering