Lightning talks from Meeting C++ 2015
meetingcpp.com
meetingcpp.com
Also, cool to see that they are considering adding a version to the language in C++17. Thought they'd ruled it out. Andrei Alexandrescu has a very nice talk on how static_if is superior to concepts, this is definitely very nice to have.
[1] https://channel9.msdn.com/Events/GoingNative/GoingNative-201...
Edit:
https://isocpp.org/files/papers/n3613.pdf
"In this paper we consider the impact and risks of adopting static if. Some of the problems addressed by the proposed feature are real and urgent, but on balance this proposal this proposal would do much more harm than good. Language features addressing these problems must not negatively affect the language and our ability to build tools around it. We conclude that future development of static if should be abandoned, and that alternatives such as “concepts-lite” approach should be pursued instead."
Concepts are nice for some things, but as Alexandrescu argues convincingly in the talk omaranto linked, they become quickly become very unwieldy if you need to consider multiple orthogonal concepts at once in the same place. You get a combinatorial explosion of things you need to name. static_if needs to much nicer and smaller code.
The wait paper you link raises some valid concerns, but if it is something you can implement just as a library (as the lightning talk shows) most of them are moot. Note that this library-only version is a somewhat restricted version of static_if, the code in the branches that are not taken is still required to parse, it just is never instantiated.
EDIT: looking again at the whitepaper, they were arguing against a specific proposal for static_if. I think this library-only version does not have the same issues.
Nice discussion here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0....
Replying to pretty much everyone: what Bjarne and others were strongly against was the first static_if proposal, which was a glorified #ifdef and broke scope rules.
The newest constexpr_if proposal does basically what I have shown in my talk (normal scope rules, no unexpected behavior), but with a nicer and cleaner syntax.