
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 12, 2015, at 7:12 AM, Gonzalo BG <<a href="mailto:gonzalobg88@gmail.com" class="">gonzalobg88@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">In the following I mean by "language extension" anything that is not in the C++11/14 draft nor accepted in the C++1z draft.</div><div class=""><br class=""></div><div class="">Since I use libc++ I've seen a tendency to enable/experiment with language extensions silently by default. This has always resulted into trouble for me: </div><div class=""><br class=""></div><div class="">Three cases come to mind:</div><div class=""><br class=""></div><div class="">- "return {...}; into a std::tuple"</div><div class="">- constexpr invoke</div><div class="">- std::bitset::const_reference</div><div class=""><br class=""></div><div class="">These extensions make sense, users might expect them, and as a consequence it is easy to use these extensions without knowing that one is writing non-portable code. </div><div class=""><br class=""></div><div class="">I like that people experiment and add extensions to libc++ and wish it would be done more often as long as the extensions are always opt-in (e.g. put behind a macro). </div><div class=""><br class=""></div><div class="">Does libc++ has a policy with respect to extensions?<br class=""></div><div class=""><br class=""></div><div class="">If so, what is this policy?</div></div></div></blockquote><br class=""></div><div>IMO, libc++ should follow the clang policy on extensions:</div><div><a href="http://clang.llvm.org/get_involved.html" class="">http://clang.llvm.org/get_involved.html</a></div><div><br class=""></div><div>-Chris</div><br class=""></body></html>