<div dir="ltr"><div>Following up with what I think the whitelist/blacklist should be:</div><div><br></div><div>Blacklist:</div><div><br></div><div>    * Variables of class type with static storage duration (including constants),</div><div>      plain old data types (POD) are allowed</div><div>        - Main reason for this is that it is hard to keep track of when these</div><div>          variables get initialized</div><div>    * Implicit conversion constructors and operators</div><div>        - Makes code confusing and difficult to debug</div><div>    * Multiple Inheritance (unless at most one of the parent classes is an</div><div>      interface i.e. only has pure virtual methods)</div><div>        - Detracts from readability</div><div>    * Non-const-non-r-value references</div><div>        - Use of const references and r-value references are encouraged</div><div>        - For non-const-non-r-value-references use pointers</div><div>        - Use where required or needed to maintain consistency with the STL is</div><div>          allowed</div><div>    * Exceptions</div><div>        - Functions have to explicitly opt out of exceptions with noexcept,</div><div>          cleaner to assume no function throws exceptions</div><div>        - No way to force exception handling (forcing handling of status objects</div><div>          is possible with the warn_unused_result attributes supported by gcc</div><div>          and clang).</div><div>        - Exceptions are not typed</div><div>        - Does not play nice with legacy code</div><div>        - We are interested in porting existing code to OpenBMC most of which is</div><div>          not exception safe</div><div><br></div><div>Other considerations:</div><div>    * Doing Work in Constructors</div><div>        - Avoid virtual method calls in constructors, and avoid initialization</div><div>          that can fail if you can't signal an error.</div><div>        - Don’t throw exceptions in constructors or destructors</div><div>        - Generally, anything that can fail should be kept out of constructors</div><div>            - Maybe a separate Init function</div><div><br></div><div>Again, the above is by no means exhaustive; it only lists features which we</div><div>propose should be completely banned.</div><div><br></div><div>On the other hand, we do not think restrictions should be placed on using virtual</div><div>functions.</div><div><br></div><div>Also, we do not feel strongly about stream operators, but would in general</div><div>object to using it as the primary grounds to not use a particular library, as an</div><div>example.</div><div><br></div><div>(sorry about any html in the previous email)</div></div>