I did some honest introspection regarding my proposal, and the exact issue I'm trying to solve. Let me come again.

A real issue (in my opinion and experience): there's lots of C++ code out there, in existing, possibly legacy (not the same as dormant/abandoned!) codebases, that we have no easy way to unittest (and were never unittested, that I'd really like to make up for), despite containing critical business logic. And I believe it is the rigidity of C++'s nominal type system that leaves us with no easy way to retroactively write unittests for such code, and presents us only with intrusive, error-prone, and therefore costly, refactoring work, before we can effectively unittest the code.

Mind you, when I say 'unit test', I am not necessarily referring to 'proper' unit testing of a single class in isolation, but rather any kind of testing that can be done with unit testing frameworks such as Google Test or Catch2, because we all know that many times, these tests are more on the level of integration tests, or sit somewhere above strict unit testing level on the testing pyramid. Regardless, any such tests are welcome, and better than not testing at all, and (in my experience) are far preferred than release testing (testing the entire codebase all at once).

I believe this issue to be serious enough to warrant a simple core language extension (if it can be proven harmless, i.e. no breaking change, doesn't hinder the evolution of C++, not generate 'language level tech debt' that will be deprecated soon, aligns with the core principles of C++), whose perhaps sole purpose is to alleviate it. This is why I was less ambitious with my proposal, and tried to find the minimal viable solution (path of least resistance), that can already be done with existing, valid C++ code. The solution I happened to find is a primitive version of duck-typing without templates.

I do read the list of upcoming C++ language and library features from time to time (using C++ 20 at my workplace as of today), and I get the feeling that 99% of them will be of no use to me, or the average programmer, but rather library authors, or compiler vendors, so I decided to try my luck here.

If anyone has a better solution, please do let all of us know.

The essence of the problem:

```cpp
// Unwieldy.hpp
class Unwieldy
{
public:
    // *One thousand members and methods*
};

// TestMe.hpp
class TestMe
{
public:
    TestMe(Unwieldy& getRidOfMe, ...);

private:
    Unwieldy& m_getRidOfMe;
};

// If only I could do this in the unit test:
class MockUnwieldy
{
public:
    // About 10 required methods
};
#define Unwieldy MockUnwieldy
#include "TestMe.hpp"
// Oh no, linker error: TestMe.cpp was compiled against the original Unwieldy :'(
```
________________________________
From: Ték, Róbert Máté (FT D EU HU OPS 6 ABP 5) <mate.tek_at_[hidden]>
Sent: Friday, August 29, 2025 7:01:56 PM
To: Jonathan Wakely <cxx_at_[hidden]>; std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Core language feature idea: structural typing support without templates

Tried to look for similar proposals, but I seem to have missed this one.

Very strictly speaking, I believe my idea is functionally equivalent to proxy_view, which seems to be a non-owning, type-erased class view with named methods, and virtually (pun intended) the same memory layout and a retrofitted vtable.

It is impressive and very ambitious. It seems to do a whole lot more than just this special case though. Interestingly, I did start out with a similar-looking prototype, which used template metaprogramming to bolt on the required member methods and function table entries.

What I am unsure about is that maybe there are caveats and edge cases to my design, that, when fully developed and solved, would result in a similarly complex design to that of the proxy library, or at least parts of it.

I decided to be much less ambitious, and tried to come up with the simplest possible design that I believe would still bring significant value to the table, with very minimal disturbance to the core language or syntax, so that it wouldn't clash with anything else, and has minimal compilation overhead, but obviously I am not the one to ultimately decide on that (:

I do feel like there are some key differences between the ideologies and intended use cases though, as well as the actual syntax of using it. I am not sure if they are enough to justify my proposal.

My proposed delegates look just like ordinary C++ classes that we've all seen before. They look and feel familiar, and have basically no learning curve to them.

If the final version of the proxy library ends up sufficiently simple and intuitive to use for my intended use case, I am sold. No further questions asked.

Else, I can clearly picture situations where I would rather use my solution, and that is high-level, non-performance critical classes, not on API boundaries, that are truly one-of-a-kind, and no 'real polymorphism' is needed; there will not be any other class (implementation) that I intend bind to that delegate ever, *except* for testing purposes.

I looked into C++ 26 reflections, but I am not sure if they could be used for what I am trying to achieve. I don't fully understand them yet.

________________________________
Feladó: Jonathan Wakely <cxx_at_[hidden]>
Elküldve: péntek, augusztus 29, 2025 12:49:09 du.
Címzett: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Másolat: Ték, Róbert Máté (FT D EU HU OPS 6 ABP 5) <mate.tek_at_[hidden]>
Tárgy: Re: [std-proposals] Core language feature idea: structural typing support without templates



On Fri, 29 Aug 2025 at 11:29, Tek, Robert Mate via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

I created a GitHub page where I fleshed out the concept in more detail and, hopefully, clarity.

You can find it here:
https://github.com/Szapi/cpp-structural-delegates/blob/main/motivation.md


Have you seen https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3086r4.pdf ? How does it compare to your proposal?