C++Now 2019: Timur Doumler “Better CTAD for C++20”

—
—
Class Template Argument Deduction (CTAD), introduced in C++17, is a useful feature that allows us to write cleaner and shorter code by omitting class template arguments. Unfortunately, the actual language rules behind CTAD are quite complex, and there are many pitfalls. CTAD sometimes deduces unexpected template arguments, and often just doesn’t work at all on certain classes, even if most users would expect that it should.

This talk summarises the actual language rules behind CTAD and its most annoying flaws and pitfalls. We will then talk about how the upcoming C++20 standard will remove some of those flaws, leading to better and safer CTAD that is easier to use.
—
Timur Doumler

Timur Doumler is a C++ developer specialising in audio and music technology, member of the ISO C++ committee, and program chair of the Audio Developer Conference (ADC). He is passionate about writing clean code, providing good tools, evolving the C++ language, and building inclusive communities.
—
---

*--*

---

[pangballping]

I am quite worried that one of the proposers of the paper about CTAD does not seem to fully understand this feature. So I have decided to simply not use this at all~

[matthiasberndt]

21:37

“Private constructors are part of the synthesized overload set because CTAD doesn't care about private because it's not going to call them. Private means you cannot call them. CTAD is not calling anything, so it doesn't care.”

This is wrong both logically and factually. Factually, it isn't true that private means you can't call a member function, it means you can't *refer* to the function by name from outside the class. But you can *call* it just fine by referring to it via a pointer if you can get hold of such a pointer.
struct Foo {
private:
void f(){};
public:
void (Foo::*g())() { return &Foo::f; };
};

int main() {
Foo f;
(f.*f.g())();
}

But even if it were true that private restricts what you can call, why would that be a reason to add private member functions to the synthesized CTAD overload set? That's a non-sequitur, so this argument fails on a logical level as well. You could easily specify the CTAD feature so that only those constructors that can actually be called in the current scope are added to the synthesized CTAD overload set.

[papamuerte]

std::cout << "cheers for this!\n";