RFE: -fconcepts support for libstdc++

[Avi Kivity]

On 01/11/2018 01:19 PM, Jonathan Wakely wrote:
> On 11 January 2018 at 11:02, Avi Kivity wrote:
>> C++ error messages are notoriously cryptic, but it's much worse when it
>> comes from someone else code.
>>
>>
>> In our code, we have a GCC6_CONCEPT(x) macro that wraps concept declarations
>> and is defined as x when -fconcepts is enabled. It would be wonderful if
>> something similar could be done to libstdc++ when -fconcepts is enabled.
>>
>>
>> Now, the concept implementation in gcc may not match the draft standard
>> exactly, but gcc and libstdc++ are developed in lockstep so when the
>> compiler changes the library can change with it. We won't be able to rely on
>> concepts for disambiguating between overloads, but they'll work well for
>> improving the quality of diagnostics.
> [N.B. This is probably better on the libstdc++ list, redirecting there]
>
> I know Ville has experimented with using concepts for std::tuple,
> because the SFINAE tricks needed there are frankly ludicrous.
>
> But I think he did it to simplify the implementation, not for better
> diagnostics, and of course you only simplify the implementation if you
> replace the old code, not if you duplicate it and have two different
> versions.

I don't think you can replace the code, because you can't require people 
to use -fconcepts for C++17 and below. It can only be an optional 
system, and therefore only useful for diagnostics.

>
> Have you found that you really do get better diagnostics when using
> concepts?

Yes. It's not earth-shattering, but it's a lot nicer to get an error at 
the point of entry into template hell, rather than 5 or 15 
instantiations down the stack. libstdc++'s implementation style with 
template base classes or members, often using EBO hacks, makes the 
payoff greater.

>   Unless we really do get significantly improved diagnostics I
> don't think the cost of maintaining two versions of complex,
> error-prone code is worth it. There's a risk of divergence in
> semantics, and it's simply harder to maintain twice as much code.
>
> But I'd certainly consider patches in this area, as long as they come
> with analysis of the error modes, the resulting diagnostics, and don't
> cause too much of a maintenance burden. As a community we do need to
> start considering how best to apply concepts in existing code,
> including the std::lib.

Perhaps we can start with std::variant, which has no old-style concepts 
check implementation (and which was the object of a complaint that 
triggered this email).