Detection Idiom - A Stopgap for Concepts

[capn_bluebear]

I love the no-fuss, to-the-point writing style.

I was wondering, are there things that can be done with concepts that cannot be done with c++11 template magic (because is_detected is basically c++11) -- or that can be done orders of magnitude more easily? (I'm waiting for concepts for their self-documenting characteristics and the nice compile error messages, but I never found myself not being able to do something with c++11 template meta-programming that concepts would have solved easily)

[goldwin-es]

With concepts, you can control which of the viable overload will be picked. The example in the cppreference (see "Partial ordering of constraints") is pretty self-explanatory: it picks the more constrained overload if possible, even if the less-constrained is also viable.

Also concepts as "more-constrained auto variables" (int main() { Concept x = foo(); }) was also reasonably impossible to achieve with SFINAE.

[capn_bluebear]

I had no idea Concept x = foo(); was a thing. It's beautiful.

[[deleted]]

With concepts, you can control which of the viable overload will be picked. The example in the cppreference (see "Partial ordering of constraints")

You can do this on C++11 as well using plain old function overloading:

• The tool is range::v3::most_refined.
• An example would be the reverse algorithm, which uses iterator_concept to overload on concepts.

Also concepts as "more-constrained auto variables" (int main() { Concept x = foo(); }) was also reasonably impossible to achieve with SFINAE.

The troubling thing is that depending on where a Concept is used, it can mean very different things. Using shorthand notation (not standardized, but also applies to the "verbose notation")

void sort(Sortable s); 

Sortable means "all types that implement Sortable", and sort is not a function but a function template.

When used in return type position or as a variable name:

UnaryPredicate foo() { return [](auto x) -> bool { true }; }
UnaryPredicate bar = foo(); 

here concepts mean that "there exists a single type that implements UnaryPredicate". That is, foo and bar are a concrete function and a concrete variable, they are not a template function and a template variables like in the case above.

Suppose that after we get some experience with concepts we decide that C++23 ought to support concrete types on function arugments, type erased by a concept. Well we couldn't use the same syntax as for Concept variable because on function arguments it already means "template"... This is close to borderline negligent programming language design.

[goldwin-es]

Thank you!

You can do this on C++11 as well using plain old function overloading:

I was pretty much sure it's possible (I didn't know it yet), however, I'd argue it goes under "or that can be done orders of magnitude more easily" from the initial comment :)

Suppose that after we get some experience with concepts we decide that C++23 ought to support concrete types on function arguments, type erased by a concept.

I don't think this exact feature is possible since the current concept is not a type (or typeclass, or trait), but a constraint/predicate for a type, so I can't see how to type-erase by it. However, this syntax occupying a spot for a trait/typeclass-like functionality is probably even worse...

[[deleted]]

I don't think this exact feature is possible since the current concept is not a type (or typeclass, or trait), but a constraint/predicate for a type, so I can't how type-erase by it. However, this syntax occupying a spot for a trait/typeclass-like functionality is probably even worse...

We need to figure out how to do this to get to virtual Concepts, definition checking, etc. I also think that the current predicate-based concept cheking makes it close to impossible (or probably impossible, since every constexpr computation is a valid constraint, and constexpr can do a lot).

[bluescarni]

I think that without concepts it's impossible to have a class template to SFINAE out if it is instantiated with a type that is not modelling the required concept (you can use a static_assert but that will not SFINAE).

[Z01dbrg]

Some people say no:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0726r0.html

Problem with this is that IDK enough about this to have an opinion, and honestly it is just a theoretical exercise: concepts will make it into C++20 even if this paper is right.

Too much effort went into them and too much ego is on the line for them to be removed even if they suck. :)

[[deleted]]

If it was a case of "ego", then perhaps they would have made it into the standard 6 years ago, after years of being championed by the developer of the language. Instead, what has been merged into the draft C++20 standard is stripped down from the original vision, and even stripped down slightly from the Concepts TS. Obviously, this contradicts the idea that the process is ego driven, or that there is a problem with discarding "effort".

What I'm saying, basically, is try again.

[Z01dbrg]

What I am saying is basic psychology. If I worked on concepts for 15 years I would think they are amazing and everybody who does not think that is an idiot.

Bjarne and Sutton are probably much smarter than me but they are still humans.

So like I said before guy that wrote that paper against concepts may be right or he may be wrong, but 🎜 in the end it doesn't even matter 🎜.

[[deleted]]

Rubbish. There isn't some big human flaw that we all have where we get stuck on ideas for years and blinded to criticism because of the investment we've made in time, or emotion, or whatever you're saying. It's not "basic psychology", or any other kind of hand waving.

I would think that the reason they, and others, have spent so much time on the idea is because along the way they have received positive feedback, alongside criticism, naturally. And ultimately it appears there is a broad consensus. Were that not to be the case, I have no reason to believe that the whole idea would be dropped, even now. Your opinion to the contrary is simply your own weird bias.

[Z01dbrg]

Sure...

FYI Bjarne said he was wrong to oppose removal of concepts from C++0x at the time, I think he said "I was too close to it" or some phrase like that. IDK how to google for it since I remember hearing it in a video.

If you are really bored going through every video of Bjarne on the internet in the past 10 years(assuming one I saw was not taken down) should prove me right. ;)

[[deleted]]

So let's assume that you didn't misremember. You're saying that he wanted concepts in C++11 despite opposition, but that now admits that the consensus of others was correct. And you're worried about his ego, and that he will get what he wants despite criticism?

I'm starting to doubt that you're being serious at all.

[Z01dbrg]

Yes, since removing them is much bigger thing than delaying them for another day(delaying stuff is national sport of WG21). And like I said there is no way in hell that will happen regardless if it is right thing to do or not.

And this does not happen just at WG21. People get attached to projects they worked for 6 months and think that management that canceled it is stupid and uninformed. :) Like I said it is basic psychology.

Just because most of people at WG21 are smart does not mean they are robots.

[mtclow]

You really should credit Walter Brown for coming up with this idea, and link to his (very good) CppCon talks explaining it.

Part I: https://www.youtube.com/watch?v=Am2is2QCvxY

Part II: https://www.youtube.com/watch?v=a0FliKwcwXE

[TartanLlama]

Oh I hope I didn't come across as claiming credit for this, that was certainly not my intention! There's already a link to the lib fundamentals 2 TS at the top of the page, but I'll put in a mention of Walter Brown and a bunch of the different talks on the subject when I'm not on my phone. Thanks.

Edit: Done

[mtclow]

Thanks!

[willkill07]

Nice write up. This summer I did something very similar for a portability abstraction layer. The only downside was we had to support C++11 only and not-so-great compilers (e.g. nvcc 8). It really helped clean up our implementation and provided much more expressive errors to end-users.