CppCon 2018: Arthur O'Dwyer “Concepts As She Is Spoke”

[@loomismeister]

In the http_request example at 8:00, don't we already get a compile time error if the template object doesn't implement body::read/write? And what do we gain from using a concept if the compile error is already being thrown?

[@UCH6H9FiXnPsuMhyIKDOlsZA]

Try it. Write that, use a bad template parameter, and look at the error you get. See if you can easily figure out what you need to change to fix it. Now imagine that, instead of that error message about no such member function "write" or whatever -- which isn't even complete, mind you -- you got "Type argument [...] does not match concept Body". Now you just look up `concept Body`, and you instantly know what you need to implement to make it work.

[@loomismeister]

@@UCH6H9FiXnPsuMhyIKDOlsZA Do you really instantly know what you need to do to make it work? I could imagine scenarios where a concept has some arcane and confusing details that make the requirement to 'match concept body' be actually very difficult. If the error message was more direct, like 'Type argument [...] must implement [X] in order to match concept Body', then you would instantly know what you needed to implement to make it work, which is exactly what the compiler already tells you when it says 'type argument has no member function 'write' or whatever'.

[@loomismeister]

@@UCH6H9FiXnPsuMhyIKDOlsZA Concepts sounded amazing to me while watching Bjarne's keynote. But after looking at this talk and understanding more about the capabilities of existing generic programming I'm just questioning the actual benefit. I definitely agree with your point that meaningful error messages is very important. And I also see that programming syntax that more clearly conveys our intent with some kind of generic template interface polymorphism as a concept is also very important.

[@UCH6H9FiXnPsuMhyIKDOlsZA]

@@loomismeister You bring up a fair point there, about complex concepts. But while they don't _solve_ that problem, they do _alleviate_ it -- imagine those complex concept requirements not being described anywhere. With a concept, even if it's difficult to read, you still have something that spells out _exactly_ what you need; with things as they are, you... don't, really. Or at least, in much harder-to-read syntax. This is especially important if you need multiple member functions, not just the one; implementing each as you get errors from the method is slower and more annoying than having a concept upfront to work from, and can also help you avoid potential design pitfalls. Concepts also allow for future expansion a little easier, though this benefit is somewhat iffier. In short, you can define a concept with _more_ than you currently need from a type, to enable future optimizations or functionality without calling code needing to change. IIRC there are also some neat compiler optimizations (as in, optimizations to the compiler itself, not optimizations to output code) and code cleanliness/static analysis things that can be implemented only with concepts. I don't know very much about compiler design or static analyzers, though, so I can't say for sure. With all that said, no, concepts aren't a silver bullet. That much is obvious, and I'm sure you're not claiming they have to be. Ultimately, it's a matter of opinion on whether or not their relatively minor benefits are worth it. In my experience, they are. In yours, they might not be, especially if your tools have good documentation. But personally, I'd rather have a single obvious blueprint for what I need to write, even if that blueprint is hard to read, rather than having to dig through template pseudo-concepts or, worse, the calling code itself. I've had to deal with some... very complex code before, and it's not fun.

[@JonathanSharman]

1:00:27 - I think the answer to this question is contracts.

[@TheSulross]

The thing about C++ generic programming is that it is as sophisticated as an undertaking as that of writing a compiler - only a rarified relative few will spend the time to master it's shear complexity - the folks that maintain the template libraries. Rank and file C++ programmers won't typically be able to spend the time to go as deep as necessary to have reasonable competence. C++ generic programming has probably always been an activity best done by an anointed priesthood while most everyone else just consumes what the priesthood provides. With advent of C++11 and now Concepts in C++20, generic programming has become very much more powerful for that priesthood, but at the same time even more remote from possibility of the rank and file. One could try to dabble in it but there is a just a vast surface area to learn in order to do it well. This is the thing about the C++ language - it is too complex for rank and file developers to master the full language - they have to settle for a working subset of the language in which they can get their day-to-day work accomplished. I was enamored with advent of C++11 for a while but am now moving on to Rust to see if is possible for rank and file developers to come close to mastering full capabilities of that language. So far am encouraged as it does much better job of nailing down ownership (move semantics), borrowing (references, slices), mutability control, and lifetimes than Modern C++. I've yet to dive that deeply into its generic programming to see how well that goes, though. And it retains a more sophisticated macro capability that is intended for use. And has some functional ideas - enums and pattern matching are rather interesting. Modern C++ is excelling with ideas such as constexpr for accomplishing at compile-time what otherwise has usually been computed at runtime - here it is definitely exceeding the thinking in the Rust community as an avenue for garnering more efficiency. And fact that Nividia has targeted C++ memory model with its latest generation GPUs and have adopted and maintain a variant of Modern C++ for programming those GPUs definitely keeps C++ language front and center in that very important arena.

[@GeorgeTsiros]

For all oaf you wheo do talks, keynoteis aned liectures, thouse of you who speaek to an auadience ion generael: Do you knoaw how tirinig it is to listen to soemeone go uuuhm and aah befoire every sentenoce? Makes it imapossible to paey atteantion to anythinyg you say. Doesan't matater how valuabale it is, it's like reading text with random vowels inserted.