<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 12, 2015 at 9:17 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Aug 12, 2015, at 7:12 AM, Gonzalo BG <<a href="mailto:gonzalobg88@gmail.com" target="_blank">gonzalobg88@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>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><br></div><div>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><br></div><div>Three cases come to mind:</div><div><br></div><div>- "return {...}; into a std::tuple"</div><div>- constexpr invoke</div><div>- std::bitset::const_reference</div><div><br></div><div>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><br></div><div>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><br></div><div>Does libc++ has a policy with respect to extensions?<br></div><div><br></div><div>If so, what is this policy?</div></div></div></blockquote><br></div></span><div>IMO, libc++ should follow the clang policy on extensions:</div><div><a href="http://clang.llvm.org/get_involved.html" target="_blank">http://clang.llvm.org/get_involved.html</a></div></div></blockquote><div><br></div><div>I think it would also be useful to have a "strictly conforming" (or as close as we can reasonably get) mode, controlled by a macro. </div></div></div></div>