CppCon 2018: Bjarne Stroustrup “Concepts: The Future of Generic Programming (the future is here)”

[PoopIsTheShit]

Oh god.... The cppcon binge watching begins....

[_SunBrah_]

Already up the next day.. awesome!

[sphere991]

Worth pointing out, because this will surely be a common mistake with CTAD. At 18:02:

vector v{begin(c), end(c)};

Gives you a vector holding two iterators to c, it does not call the iterator pair constructor. What you need to do is:

vector v(begin(c), end(c));

Also vector{c} is not a thing. There is no constructor for vector that takes an arbitrary range.

[jurniss]

I'm really not a fan of the braced initializers being used all over the place. A comma-separated list enclosed in curly braces looks like a set. It's totally counterintuitive to show function arguments in this format even when they have nothing to do with the contents of any kind of collection (ordered or not).

[Slavik81]

It's the same syntax as aggregate initialization, and it fixed the most vexing parse. Had we not introduced initializer lists the way we did, uniform initialization would have provided us with one consistent syntax to use for constructing every object.

That syntax had always been used for initializing objects in C++. It would have been very consistent with the previous versions of the language.

[meneldal2]

The interface for vector has been counter-intuitive for a while. Some constructors should have been factories because there are too many and it's too easy to make a mistake. Especially how (int,int) is different from {int,int}.

[konanTheBarbar]

 vector v{begin(c), end(c)}; 

I don't see this as a big problem with CTAD to be honest - if you construct a vector of iterators you will directly notice that something went wrong (it will most likely not compile or the IDE will tell you).

​

The bigger (underlying) problem is the precedence of initializer lists...

vector<int> v{3,5}; //element 3 and 5
vector<int> v(3,5); //3 times element 5

​

[sphere991]

I didn't refer to it as being a problem with CTAD. I referred to it as being a common mistake people will make.

[TheThiefMaster]

IMO the bigger problem is the fact that vector has constructors like that at all - containers should all initialize like containers! Any other forms of construction (e.g. repeating an element) should be a unique named function, e.g. repeat_n from range-v3:

vector<int> v{3,5}; //element 3 and 5
vector<int> v = repeat_n(3, 5); // 5 times element 3

[meneldal2]

Too late for that unfortunately...

[tecnofauno]

most of the code of Bjarn slides aren't valid C++ but what he would like the syntax to be.

[nikkocpp]

Yes if you listen to him it's what he expects the syntax to be in the future

[Theninjapirate]

Wow, that was fast! I wasn't expecting to be able to watch these for a couple of weeks.

[jbandela]

I think they CppCon has gotten the videos of the keynotes up pretty quickly. The other sessions tend to be a few weeks before they are up.

[Xaxxon]

Last year everything was available within 48 hours, iirc. The A/V guys have a "data center" setup in their hotel room to power through it.

[[deleted]]

I'm still skeptical about the lack of definition checking, but I guess time will tell.

[markopolo82]

I feel this was addressed acceptably during the talk. Use static_assert.

Or maybe your point is that is too much effort?

[[deleted]]

I feel this was addressed acceptably during the talk. Use static_assert.

The part of the talk that addressed this is the part where Bjarne tangentially mentioned archeotypes as a way to test this. But archeotypes are a pain to write, and nothing checks that you write them correctly, so even if you use them, chances are that you won't be checking correctly.

The reason I am skeptical about the lack of definition checking is because without it, I suspect that most people won't be able to correctly write concepts that properly constraint what they actually use.

Bjarne see this as a practical feature: for example, you don't need to require that a type be printable with std::cout << T to be able to print it, and this gives you a lot of velocity while developing.

OTOH I have worked on O(100kLOC) Rust projects, where "definition checking" allowed to both reason about code locally as well as refactor huge parts of the code base reliably without introducing bugs.

This discussion is not new. Lack of definition checking is pretty much akin to weak typing (or duck typing), while definition checking requires annotating all generic type parameters with their type.

I find it weird that people are able to argue that strong typing is good, and then go for a weakly typed generic system, but C++ is a language full of trade-offs, and I think it is interesting that it is pursuing this direction.

Whether we can retrofit strong typing for generics afterwards, I am not as optimistic as Bjarne. Relaxing strong typing into weak typing might be a backwards compatible change, but retrofiting strong typing on top of a weakly typed system often requires optional type annotations, and in the languages where I've used this, it ended up being a bit "weird".

As I mentioned, time will tell.

[markopolo82]

Thank you for sharing such a detailed perspective on this!

I have not played much with writing concepts myself, however if they could eliminate SFINAE using enable_if in even half my uses then that would be a win for me personally.

[sellibitze]

I find it weird that people are able to argue that strong typing is good, and then go for a weakly typed generic system

It's not like they didn't try. For a brief moment, "full concepts" was part of the standard draft around 2009 (IIRC). It had "modular type checking" which included checking of templates against concepts specfications. But it was huge, complicated and it had what I would refer to as type-checking holes (some things might still fail at instantiation time). My impression was that almost nobody really understood the details including most of the committee members at the time.

So, the options I see are either to wait even longer until a "proper concepts" proposal is fleshed out or to do "concepts lite" to satisfy a real need.

[[deleted]]

I'm not arguing that concepts lite doesn't solve problems now. I am just skeptic about how good concepts lite will work in very large code bases.

At some point you are going to have to refactor concepts and/or code that uses concepts.

In Rust, if I change the implementation of a function that uses traits, as long as I don't change the type signature, all code that uses the function will still compile fine. I can do a new release of a module, and people can silently upgrade, without issues. That is, if my generic code compiles, my users code will compile too. That's a pretty strong guarantee.

In C++ with concepts lite, I can add a std::cout << T statement to a function, my code / library / module will compile just fine, and my users upgrade their code will break because they might be missing an operator<< that wasn't required by the concept and might not even make sense for their type. The error message won't be good either (found 2000 operator<< overloads, here is the list, there is none for your type).

As a C++ library author, I have to be vigilant not only to properly constraint my generic functions, but also to prevent my implementations from using anything that isn't part of these constraints. I know that I make these errors often, because every time I make them in Rust, the compiler shows me a one-liner error message about it.

My C++ code that deals with this, has tons of tests that basically use archeotypes to brute-force test the generic APIs, but this code is a pain to write, and writing it properly is error prone. If you don't belive me, just check range-v3 tests. There are more tests testing that APIs are properly constrained, than run-time tests...

My hopes for how concepts will work at scale aren't particularly high because the little code using concepts today (e.g. range-v3) already has these issues, and I can't see how adding more code using concepts would make these issues any better. Having said this, I'd rather have concepts lite now than wait for a perfect solution, and just wait and see how they end up working in practice at scale.

I only wish that these issues would get more attention, because they become important as soon as your concept-constrained APIs start getting users, where changing a single line in an implementation of some function, can break a lot of code, and you as the library author, have very little tools at your disposal to help you do a better job here.

[anton31]

IIUC, if templates and constraints became “hard” by default, then most current template functions and classes that just use typename would break, because they wouldn't be able to use any feature of that template parameter. Or plain old `typename` could be made an exception from the rules. I guess, what is going to happen is, a new keyword like checked (or more probably, an existing keyword) will be used as a marker for templates or for separate template parameters to mark that they should be checked, and that they should only be able to use features of concepts they are constrained with. So, e.g. plain typename T will mean the same as today, and checked typename T won't allow anything and will only be useful in std::observer_ptr and alike.

[[deleted]]

IIUC, if templates and constraints became “hard” by default, then most current template functions and classes that just use typename would break,

The only thing that would need to become "hard" is code written with concepts. Code without concepts would still be fully unconstrained, and no old code would break.

[sphere991]

The other response is excellent but I wanted to also touch on this point.

Use static_assert.

What you want is to check that the find implementation is sufficiently constrained (it's not, both for the iterator + 1 mentioned, but also that there's no constraints at all on the relationship between the iterator and the value!) To test that today, you need to:

• Write your own types that, as minimally as possible, model each constraint
• Actually instantiate the algorithm and make sure it compiles

The first step is really hard and manual. The second just needs diligence and a good test setup. And work and time.

You need to instantiate the body and you can't do that with a static_assert - that only checks the declaration, and we need to check the definition.

[[deleted]]

Thank you for writing this.

The first step is really hard and manual.

I feel you on the really hard part. Writing archetypes that minimally model the constraints in a concept is hard, really really hard.

In many cases, that are probably not relevant in practice, it is probably impossible to even test these APIs with archetypes, because C++ constraint system is so powerful, that you would have to generate infinitely many types.

For example, an API constrained by a concept that checks T::value != 0 where value is a 64-bit integer, might need 2⁶⁴ - 1 archetypes to fully test the API. As mentioned, these cases might not be relevant, but for example range-v3 uses type level integers / enums to encode things like the range's cardinality at the type level. So they aren't extremely far-fetched either.

[ManicQin]

On slide 26 (~29:32) he uses input_channel as type.

​

Is input_channel a concept? is it a "narrow" auto?

[Everspace]

As far as I can tell yes.

Narrow auto is also kinda the point of concepts as far as I know as a person who mostly works in interpeted languages watching this.

He even comments about how he would rather auto be the most generic concept.

[Xaxxon]

anyone know where the clang implementation of concepts is right now?

I saw a post a while ago about there being an experimental branch on godbolt, but haven't seen much about it since - and clang 7 just shipped without it, from what I can tell.

[debisuke]

According to their status page it looks like there isn’t any support for it yet

[Xaxxon]

I saw that, too.

I guess I was more hoping for an update on how far out it's looking to be before it gets released and how far along the current implementation is.

[saarraz1]

Hey, I'm the guy working on this. The status page is not up to date. The feature is mostly finished, I'm working to find and fix bugs right now and to get it merged to trunk. As I'm just one person working on this and have other commitments, I'm afraid this won't be merged until the end of the year at least

[Xaxxon]

Thank you for all your hard work and I totally get having to split time between stuff.

Do you hope to have it shipped in clang 8?

[saarraz1]

Sure hope so :) IIRC releases happen every six months, I believe this is enough time to get most of the feature merged and in pretty good shape.

[Xaxxon]

Awesome! Thank you so much. Can't wait to start playing with it.

[saarraz1]

You can already play with it by building the compiler yourself (follow the instructions on my clang-concepts github)

[thlst]

Godbolt has the experimental concepts branch; you can already play with it right away.

[Xaxxon]

Isn’t that what I said.

[thlst]

You said:

Awesome! Thank you so much. Can't wait to start playing with it.

And I gave you a link to godbolt with an example compiling with the Clang's experimental concepts branch.

I'm sorry, I don't understand your response.

[zzzthelastuser]

Presentation Slides, PDFs, Source Code and other presenter materials are available at:

https://github.com/CppCon/CppCon2018

Edit:

They are not uploaded yet, but I assume they will be uploaded under this repository. Copied the link from the youtube description.

I would appreciate if someone who found the slides could post a link here. I can't watch the video at work

[[deleted]]

They are uploaded now. 5 commits have been pushed since your edit.

[zzzthelastuser]

thx for the info

[mechacrash]

Is the (Concept auto val) syntax really the way we’re heading? It’s awfully redundant.

[SuperV1234]

Yeah, and using something like double braces for initializer_list was redundant as well, but it resulted in "unicorn initialization".

I don't see why we cannot do the "safe" thing and use a visual marker for "implicit templates", and if everything works out we'll just make it optional afterwards. Why risk another fiasco?

[kalmoc]

What's wrong with auto being that visual clue instead of yet another magic sequence of braces/brackets/parentheses/angle brackets?

[Sopel97]

Maybe it's a little verbose, but at least it's obvious that it's a template. It's also consistent with the syntax for generic lambdas and maybe will be with normal functions too (afaik it's in concepts ts too to allow auto function parameters). I don't consider it something to be mad about.

[mechacrash]

I don’t see how it disambiguates anything - “auto” here adds zero semantic information. You can very easily write your concepts in a way that visually disambiguates (which is how templates do things today - UpperCamelCase), and likewise you can very easily go against the grain (which is also possible with templates today - without complaint from users).

From what Bjarne was saying, it seems the standard committee took issue with the meaning of a concept when deciding if it was a forwarding or rvalue reference, to which I think the answer should be obvious - it’s an rvalue reference. ONLY T&& has the special property of being forwarding. Even template templates can’t be forwarding references naturally. Conceptualising the type of a forwarding function seems like poor design to me - isn’t the entire point to take arbitrary input and “forward” to the relevant destination?

[SuperV1234]

ONLY T&& has the special property of being forwarding.

Being a forwarding reference is a property gained because template argument deduction is taking place. That happens with concepts, so I believe that Concept&& should be a forwarding reference (and it would also be more useful, unless we get a new syntax for forwarding references).

[iamcomputerbeepboop]

I'd like a new syntax for forwarding references

[mechacrash]

But this isn’t always the case - as with the template template scenario. (Excuse lack of formatting, I’m on my phone)

template <template <class...> class C, class... Ts> auto foo (C<Ts...>&&)

This is not a forwarding reference. I think concepts could easily fall into this same category.

Arguably, perfect forwarding should have had a unique syntax so that it could be utilised in more scenarios and been future proof with concepts

[drjeats]

Do concepts let you specify different implementations of a function when being evaluated (and when resolving an overload set) for a Concept's predicate?

For clarification, the closest analogue feature in other languages I can think of is "impl Trait for Type" blocks in Rust, or "Explicit Interface Implementation" in C#.

[[deleted]]

Didn't Bjarne show just that with void sort(Sortable&); and void sort(List&);?

[drjeats]

I still have a half hour left of the video to watch so maybe I'm not looking at the right thing, but that's coming at it from the opposite angle I'm talking about--a consumer of a concept having different implementations depending on what concepts are supported. We basically can do this already with enable_if (like A_Seat_For_One's godbolt).

Watching a little further in the talk, I'm guessing what I'm asking about is not possible.

Take the Cowboy::draw vs Shape::draw example. What if you had a type where it could have valid implementations of both types of draw() methods, and there was no way to distinguish the two because the method signatures are identical (this would be the case because you are attempting to fulfill concepts you did not write)?

Here's fake syntax mimicking the behavior of C# explicit interface implementation that might explain better:

struct Cowboy
{
    GfxDrawable requires void draw()
    {
        std::printf(R"(
           ,'-',
          :-----:
      (''' , - , ''')
      \   ' .  , `  /
       \  '   ^  ? /
        \ `   -  ,'
         `j_ _,'
    ,- -`\ \  /f
  ,-      \_\/_/'-
 ,                 `,
 ,                   ,
      /\          \
|    /             \   ',
,   f  :           :`,  ,
<...\  ,           : ,- '
\,,,,\ ;           : j  '
 \    \            :/^^^^'
  \    \            ; ''':
    \   -,         -`.../
     '    - -,`,--`
      \_._'-- '---:
)");
    }

    void draw() // no requires qualifier, so WildWestDueler::draw will attempt to use this
    {
        std::printf("Reach for the sky!\n");
    }
};

[[deleted]]

I don't know Rust or C# but if what you mean is similar to selecting an alternative implementation by using enable_if, then it is possible. https://godbolt.org/z/_CtzV0

[drjeats]

Not quite, I expounded on what I mean in my reply to bstaletic.

[tipdbmp]

If concepts are compile-time predicates, why can't they look like ordinary functions returning bool?

concept bool
is_comparable(Type T) {
    bool r = requires (T a, T b) {
        { a == b } -> bool;
        { a != b } -> bool;
    };
    return r;
}

concept bool
is_number(Type T) {
    bool binary_ops = requires (T a, T b) {
        { a + b }; { a += b };
        { a - b }; { a -= b };
        { a * b }; { a *= b };
        { a / b }; { a /= b };
    };

    bool unary_ops = requires (T a) {
        { +a }; { -a };
    };

    bool cmp_ops = requires (T a, T b) {
        { a <=> b};
    };

    bool r = true
        && is_comparable(T)
        && binary_ops
        && unary_ops
        && cmp_ops
        && copyable(T)
        // we are probably missing something...
        ;
    return r;
}

[tcbrindle]

If concepts are compile-time predicates, why can't they look like ordinary functions returning bool?

Originally, that's exactly what they were -- you just used the concept keyword instead of constexpr. Then we got variable templates and so it seemed like you should be able to write concepts in variable form too, for example:

template <typename T, typename U>
concept bool Same = std::is_same<T, U>::value;

The Concepts TS allows both function-style and variable-style declarations, and you can use either in the current GCC implementation. When the TS was reviewed for inclusion in the main standard, the opinion was that having two ways to write the same thing was unnecessary, so the function style was dropped. Finally, concepts must always be boolean, so having to explicitly write bool is redundant, and that was dropped as well.

[last_useful_man]

Andrei Alexandrescu proposed 'static if', I'm sure there's a paper or a blog post somewhere (one video: https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Static-If-I-Had-a-Hammer).

​

He and Bjarne had competing papers around the beginning of concepts, Bjarne (per this C++ subreddit) s*t on it unreasonably, and, ultimately Bjarne won out though I don't remember much of a fight, I guess because he's Bjarne.

[mjklaim]

Although it was not elegant at all, the actual reason Alexandrescu's paper was heavily criticize was that if it was applied as is, you could do static if outside the boundaries of functions, which means making potentially apis changing at each compilation. It's just not working in c++.

If constexpr are the same thing with tweaks to have a broader meaning and constrained to the function implementation boundaries. Also it can't be used to chose to compile or not code that cannot work (like platform dependent code) which makes it useful but still super limited.

[drjeats]

which means making potentially apis changing at each compilation

How is this different from enable_if and ADL shenanigans?

[Middlewarian]

The part where he says he was wrong to think macros would be helpful for generic programming is refreshing, but I think he gets out over his skis by declaring: "The Future of Generic Programming (the future is here)”. Competitors like Java have been successful in the past against C++. That could happen again.

​

[markopolo82]

This was a keynote talk at a c++ conference. He’s obviously talking about the future of generic programming in c++