Preventing a class from allocating automatic local variables on the stack sounds more like C++ profiles.   E.g. for preventing stack overflow conditions on safety critical systems.   How much overlap is there between tagged classes and profiles? How do they differ in usage requirements?   E.g. for safety one could demand that all code follows certain profiles. Or all code directly or indirectly called from a a function (e.g. the main function of a thread).   How are those requirements expressed in source code?   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 28.05.2024 12:43 Betreff:Re: [std-proposals] How should we tag a class? Use an empty base class or a typedef? An:std-proposals <std-proposals_at_[hidden]>; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Tue, May 28, 2024 at 12:48 AM Arthur O'Dwyer wrote: > > You have to re-opt-in to `is_library3_thing` at each level > of inheritance (that is, at each leaf) I think there are two kinds of tag you would want to put on a class:    (1) Hereditary    (2) Terminal With hereditary tags, a derived class must opt out. With terminal tags, a derived class must opt in. And so a hereditary tag system would work like:    class MyClass {    public:        typedef std::true_type tag_elide;    }; And a terminal tag system would work like:    class MyClass {    public:        typedef MyClass tag_elide;    }; But instead of using typedef's for this purpose, should we instead be talking about adding "Class Tagging" to C++26? It would work as follows:    class MyClass1 {    public:        tag [elide] hereditary;    };    class MyClass2 {    public:        tag [elide, some_other_tag] terminal;    }; And then instead of creating a separate concept to use as a constraint, you would just do:    template<typename T, typename R> requires tagged[elide, some_other_tag]<T,R>    void Func(void)    {        // Both T and R must have the tags "elide" and "some_other_tag"    } If we take it a step further, the core language could then even interact with tags that the programmer has put on their own custom classes. So for example, let's say we name a tag "no_local" and we put it on our class "MyClass" as follows:    class MyClass {    public:        tag [no_local] hereditary;    }; And then we try to make a local variable:    int main(void)    {        MyClass obj;  // compiler error -- cannot make on the stack        MyClass *p = new MyClass;    // This is okay    } This would be a neat way of making sure massive classes don't get allocated on the stack. I'm sure there's a hundred other uses for this. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals