About using concepts:   Concepts allow to specify required members, but it is actually more like a boolean test than an interface signature specification.   One either specifies  - that the feature demands some suitable concept definition, has to be well-formed for std::any<concept> or  - makes it clear(er) in syntax/C++ language that this is an interface  - separates the member list/interface from the concept, perhaps not all members should get a dispatch entry     Will this work only on public members, with any access specifier or at a certain point in the program there has to be allowed access, e.g. at the constructor call of std::any?   The logical point would be, wherever the members are called, but at that point the class is not known at compile-time, only the dispatch is used.   -----Ursprüngliche Nachricht----- Von:amngis_21d38 via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 17.05.2026 05:05 Betreff:[std-proposals] Interest check: Constrained runtime type erasure via concepts An:std-proposals_at_[hidden]; CC:amngis_21d38 <amngis_21d38_at_[hidden]>;     Hi all,  I'd like to gauge interest in a language/library feature that bridges C++20 concepts with runtime polymorphism.  **Problem:** C++20 gives us powerful compile-time concepts, but when we need to store heterogeneous types in a container (e.g., a vector of "anything drawable"), we must choose between: - Templates (no runtime flexibility) - Manual type-erasure boilerplate (Sean Parent's runtime concept pattern, ~50+ lines per interface) - std::any (unsafe any_cast, no interface enforcement)  **Idea:** Introduce a concept-constrained erased type, spelled std::any<<Concept> or std::dyn<<Concept>, which: - Accepts only types satisfying the concept (compile-time check) - Exposes the concept's required members as directly callable methods - Requires no inheritance, no virtual functions, no manual vtable authoring  Example:   template<typename T>   concept Drawable = requires(T t) { t.draw(); };    std::vector<std::any<<Drawable>> scene;   scene.emplace_back(Circle{1.0});      // OK, satisfies Drawable   scene.emplace_back(Rectangle{2.0, 3.0});// OK   // scene.emplace_back(42);            // Error: int does not satisfy Drawable    for (auto& s : scene) {       s.draw();                         // Direct call. No any_cast.   }  **Prior art:** - Rust's dyn Trait, Swift protocols, Go interfaces (non-intrusive runtime   polymorphism with compiler-generated witness tables) - Library approximations: woid, dyno, te (but require heavy boilerplate or   macros)  **Questions for the group:** 1. Has this direction been discussed before in EWG/LEWG? 2. Is there appetite for a core-language mechanism to auto-generate dispatch    tables from concept requirements, or would a pure-library solution based    on reflection (P2996) be preferred? 3. Should this overload std::any<<Concept> or introduce a new vocabulary type    (std::dyn<<Concept>)?  I have a more detailed draft if there is interest. Thanks for your time! -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals