Hi Mehmet, could you give some examples, what you would turn on/off to clean up or give more design space? I could at least imagine the very different scopes A-H, which all somehow fit to your description, but would receive totally different arguments in favor and against. A) Everything, which is often handled by compile switches nowadays from warning levels over library paths and optimization levels to coprocessor behavior   B) Signify standard version only, no need for specifying in makefile. But then please specify, what would change (more) than with status quo   C) Features, which are not recommended for modern C++ like C arrays   D) Features, which are not recommended for user code like new/delete (instead of smart pointers) - i.e. introducing different code levels like system/library/user   E) Parser difficulties like Most Vexing Parse or comma-operator for multi-dimensional arrays   F) Bad historic language defaults, e.g. user-defined constructor should automatically delete copy constructor and copy assignment operator or one-argument constructors should not do implicit conversion   G) New parser model with freely definable (Unicode) operators with configurable precedence and associativeness (left/right); pipes, range filters or parallel processing hints should be defined in a nice way (and not misuse arithmetic operators).   H) Language should be customizable like begin/end instead of {}, if one chooses   If you would be more specific with the scope you intend, the feedback could be better measured to what you actually propose.   -----Ursprüngliche Nachricht----- Von:Mehmet Kayaalp via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 26.11.2022 22:31 Betreff:Re: [std-proposals] Pragmas using multiple C++ standards within the same project An:std-proposals_at_[hidden]; CC:Mehmet Kayaalp <mehmet.kayaalp_at_[hidden]>; Thiago, Sebastian, Bo, and Arthur: Thank you for your feedback and drilling questions. Based on your input, I revised the following sentence to disambiguate my intention (see the italicized parts):  I fail to understand why we don’t come up with new preprocessor/compiler directives for each translation unit, indicating which compiler version should compile it to produce the intended assembler code (instead of compiling the entire set of codes with a single compiler). You all noted that this has already been done by others. But all mentioned solutions were outside of C++ standards; thus, they do not affect the decision-making of the C++ standardization committee. Without an intrinsic C++ solution that enables us to use the existing libraries and legacy codes, the C++ standardization committee would not attempt to eliminate the old baggage, simplify the language significantly and make the new C++ a more coherent language. > Why do we have to "eliminate" the old features? Just stop using them! The backward compatibility requirement (along with the long legacy of C and C++) makes the modern C++ language very complex, making it too difficult for newcomers to embrace and learn the language and master the language in its entirety. A simpler and more coherent new standard can be embraced by newcomers easily and would provide developers with explicit guidelines about the preferred features of the language. By ignoring this, we would be making C++ less and less popular in the coming decades. We all can agree that such a new standard would not have all the bells and whistles of the current language, but with the proposed approach, one can always fall back on using the deprecated features supported by older standards for more flexibility and control. Best, --mehmet kayaalp -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals