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/01/18 13:39 +0200, Ville Voutilainen wrote:
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.

I think gnu-versioned-namespace is that mode.

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.

That's what I'm afraid of.


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