```

10: rjk::duck<Container> c{std::vector<int>{1, 2, 3}};

11: c.size(); // 3

12:

13: c = std::string{"hello"};

```

Does the assignment on line 13 call the destrucor for the vector of ints created on line 10?

It’s a bit like a well-kept Victorian home. The amount of work, money, and dealing with discomfort that goes into maintaining one isn’t something I really want to experience for myself. But the amount of skill and craftsmanship that it takes to preserve one is still impressive, and I have to appreciate the respect for history and the care that goes into balancing it with modern concerns.

And talking to people who do live the life is always a great learning experience.

I used to think that was a personal limitation, until I saw an interview with Bjarne explaining that he used to understand all of it but at this point it’s too big, no one can anymore.

As an aside, you may want to check out Jai's approach. I believe everything you generate statically gets turned into a file by the compiler for debugging purposes, which it provides references to in the output.

Those against IDEs, well they already voted against good tooling in first place.

One reason is that, like you said, the feature is still new. Additionally I made pretty liberal use of the std::ranges library in my implementation which has notoriously bad compile times. That could be an area to improve upon.

Another may be a bit more structural. If you want to call myObj.foo() via reflection, you have to linearly search members_of(myObj) for the one named "foo", and then call that. Actual compilers I assume use some kind of hash table.

The hand-waving solution is "put it in a PCH", but I am hoping to put some more effort into optimizing build time here in the future.