GNOME Bugzilla – Bug 765214
3.0: Use of C++ concepts
Last modified: 2018-07-10 22:47:49 UTC
Created attachment 326259 [details] [review] 0001-concepts-bind-Use-the-origin-Copy_constructible-C-co.patch Even though concepts won't be in C++17, I'm still interested in trying them. And they can even be compatible with regular C++ when we use this syntax, if we use and ugly #define to typename: #define SomeConcept typename template<SomeConcept Thing> class Stuff { Thing thing; } g++ 6 (not yet released) supports C++ concepts via the -std=c++1z and -fconcepts options (I think both are necessary, but I'm not sure), and the Origin library provides some concepts: https://github.com/asutton/origin Here is a small patch to just use one concept to make sure that bind() takes copyable arguments to bind. It's not particularly useful. I was hoping to somehow mark the various T_Functor types as invokable, but I can't find a useful way of using Origin::Invokable.
What I really like in sigc++ library, is that it's not depended on third-party libraries, so I'd rather avoid using Origin library. Moreover, as you said, concepts is not a part of C++17, and nobody knows when this feature will get into the language. Instead of waiting, we could do the same with static_assert's and enable_if's. If you agree that we should go that way, I could provide patches.
Yes, of course, we would not really depend on the origin library. It's just a way to get concept definitions now that are likely to be correct, and generic. When we use concepts we might use official concept from the C++ standard library, and some of our own. For static_asserts() and suchlike, yes, that would be interesting: https://bugzilla.gnome.org/show_bug.cgi?id=759245
According to https://libsigcplusplus.github.io/libsigcplusplus/devel.html the issue tracker of libsigc++ is located at https://github.com/libsigcplusplus/libsigcplusplus/issues nowadays. If the problem in this bug report still exists in a recent version of libsigc++ please file this bug report in GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping, as we plan to shut down GNOME Bugzilla in favor of GNOME Gitlab.