[PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations

Jonathan Wakely jwakely@redhat.com
Wed Apr 3 22:30:00 GMT 2019

On 03/04/19 23:39 +0300, Ville Voutilainen wrote:
>On Wed, 3 Apr 2019 at 23:32, Antony Polukhin <antoshkka@gmail.com> wrote:
>> Looks good. Covers most of the use cases.
>> Please consider adding filesystem::path, pair, tuple, string_view?, error_code, list, deque (myabe all the other containers), optional, variant itself (for cases when variant holds another variant).
>> It would be very useful for the _Never_valueless_alt to return true for aggregates that hold only never valueles types. Not sure that there is a compiler builtin for getting all the aggregates types, but it could be implemented via metaprogramming.
>What metaprogram is capable of that?

I think it would need a compiler builtin like __bases and
__direct_bases, which we don't have (and couldn't use unless it was
already implemented in every compiler that uses libstdc++).

>> When is the ABI freeze for the C++17 additions?
>This approach concerns me; it's a "get it right at the first chance
>and then never change it", which is.. ..awkward. But I don't know
>whether there's any
>way around that.

To some extent that's the case every time we declare something
non-experimental. There are things I'd change about
std::__cxx11::string if I was doing that again, but we're stuck with
what we have.

At least for these never-valueless variants it's just a QoI
optimization, and if we don't make it work for every possible type it
doesn't matter much.

More information about the Gcc-patches mailing list