Date: Thu, 28 Aug 2025 07:54:47 -0700
Hard to say: there needs to be something more concrete here. What is that
basic version, what compile-time and runtime costs does that impose, etc.
Also, why limited to C++20 (since we’re talking about some change/extension
to the Standard), why not use 23 features (at least), or 26 since it’s just
around the corner and will be published before your proposal could possibly
make it through the committee?
On Thu, Aug 28, 2025 at 7:29 AM Tek, Robert Mate via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Having worked on a couple larger (we can call them legacy) C++ projects
> full-time, I found myself wishing for some level of structural typing
> (duck-typing) support in C++.
>
> It is very difficult to add new features/functionalities to existing
> codebases, which may or may not be well-structured in terms of modularity
> and code coupling.
> I believe that most C++ projects above a certain size and complexity will
> suffer from these issues, that is, dependency hell, overgrown and
> un-mockable, un-unittestable mega-classes that contain important business
> logic.
> The issue is not that these classes are untestable, it’s that every other
> code that use them, are also rendered untestable.
> There are conventional ways to deal with this in C++, but that usually
> means tedious refactoring work, or too much boilerplate, and can introduce
> bugs, and so the code is never properly ‘cleaned up’.
> I also feel like there may be situations where nominal typing just doesn’t
> cut it.
>
> When new features are to be added to a codebase like this, I often find
> myself reaching for type erasure tools (e.g. std::function), dependency
> injection, callbacks, etc, so that the newly written codes can be properly
> unit tested, and of course follow good coding principles and practices.
> If I have time, I will usually try to refactor the old at the boundary
> with the new, and expand the unit test coverage, but this is easier said
> than done. There’s usually dependency issues and interface fragmentation to
> deal with.
>
> I tried my best to come up with good conventional solutions in these
> situations, and I just wasn’t fully satisfied with any of them.
>
> So I played around with the idea of structural typing, and I successfully
> made a working structural delegate class with type erasure and method
> binding, with existing C++ 20 features, and AFAIK it is perfectly valid and
> safe C++ code. The issue is, it’s not feasible to write by hand. Not even
> with macros. The best I could come up with is a python code generator that
> spits out a single-header (well, two-header) delegate class with a given
> public interface.
> It could be used to (almost trivially) refactor existing codes to decouple
> classes, get rid of dependencies, etc, and I sincerely believe it would
> help all of us write better code.
>
> So I guess my question is, what do the C++ experts think about adding more
> structural typing support to the core language? I think a basic version of
> structural delegates could be added to the language as a purely optional,
> non-intrusive extension.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
basic version, what compile-time and runtime costs does that impose, etc.
Also, why limited to C++20 (since we’re talking about some change/extension
to the Standard), why not use 23 features (at least), or 26 since it’s just
around the corner and will be published before your proposal could possibly
make it through the committee?
On Thu, Aug 28, 2025 at 7:29 AM Tek, Robert Mate via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Having worked on a couple larger (we can call them legacy) C++ projects
> full-time, I found myself wishing for some level of structural typing
> (duck-typing) support in C++.
>
> It is very difficult to add new features/functionalities to existing
> codebases, which may or may not be well-structured in terms of modularity
> and code coupling.
> I believe that most C++ projects above a certain size and complexity will
> suffer from these issues, that is, dependency hell, overgrown and
> un-mockable, un-unittestable mega-classes that contain important business
> logic.
> The issue is not that these classes are untestable, it’s that every other
> code that use them, are also rendered untestable.
> There are conventional ways to deal with this in C++, but that usually
> means tedious refactoring work, or too much boilerplate, and can introduce
> bugs, and so the code is never properly ‘cleaned up’.
> I also feel like there may be situations where nominal typing just doesn’t
> cut it.
>
> When new features are to be added to a codebase like this, I often find
> myself reaching for type erasure tools (e.g. std::function), dependency
> injection, callbacks, etc, so that the newly written codes can be properly
> unit tested, and of course follow good coding principles and practices.
> If I have time, I will usually try to refactor the old at the boundary
> with the new, and expand the unit test coverage, but this is easier said
> than done. There’s usually dependency issues and interface fragmentation to
> deal with.
>
> I tried my best to come up with good conventional solutions in these
> situations, and I just wasn’t fully satisfied with any of them.
>
> So I played around with the idea of structural typing, and I successfully
> made a working structural delegate class with type erasure and method
> binding, with existing C++ 20 features, and AFAIK it is perfectly valid and
> safe C++ code. The issue is, it’s not feasible to write by hand. Not even
> with macros. The best I could come up with is a python code generator that
> spits out a single-header (well, two-header) delegate class with a given
> public interface.
> It could be used to (almost trivially) refactor existing codes to decouple
> classes, get rid of dependencies, etc, and I sincerely believe it would
> help all of us write better code.
>
> So I guess my question is, what do the C++ experts think about adding more
> structural typing support to the core language? I think a basic version of
> structural delegates could be added to the language as a purely optional,
> non-intrusive extension.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-08-28 14:55:00