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


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