This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFE: -fconcepts support for libstdc++


On 11 January 2018 at 13:19, Jonathan Wakely <jwakely.gcc@gmail.com> 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.

Yep. That was indeed more an experiment in seeing what the
implementation would look like with concepts
focusing on the constraints and the overload set, not on the
diagnostics. Some results of that work could be
folded back into the current implementation (ConstructibleTuple and
MoveConstructibleTuple can be combined),
but as far as diagnostics go, the real poison is in the amount of
overloads, which the compiler dumps in
the case of no match.

That could be improved with conditional static_asserts (but that
doesn't work in C++03 mode, which is not a problem
for tuple but is for pair) and by triggering
those static_asserts via if constexpr (but that doesn't work in C++14
mode and below), and making it something
that works in every mode but better in modern modes probably needs
fair amounts of implementation heroics.

I keep toying with the idea of providing a forever-experimental
bleeding-edge mode where the user would opt in to latest and greatest
library facilities with no promise of ABI compatibility, but I also
keep putting that off due to more urgent fish to fry.

> Have you found that you really do get better diagnostics when using
> concepts? 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.

Based on my experiments, I wouldn't want to try and do a pre-concepts
implementation and a concepts implementation
muddled together. Sure, some parts of it can be macro-magicked to use
enable_if or requires, but again, that requires
fair amounts of heroics. But whichever way something like that is
done, either by one implementation that really compiles
to two or more, or by separate implementations, the maintenance burden is there.

> 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.

Having to support earlier standard modes makes this hard. I agree on
considering patches, but this sort of code can end up
being very messy with relatively little benefit.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]