Date: Fri, 29 Aug 2025 17:01:56 +0000
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?
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?
Received on 2025-08-29 17:02:03