'Re: [cfe-dev] [libcxx] Policy with respect to language extensions'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] [libcxx] Policy with respect to language extensions
From:       Chris Lattner <clattner () apple ! com>
Date:       2015-08-12 16:17:50
Message-ID: C3335B1F-CD49-4FB6-B6D2-667F27A34894 () apple ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

> On Aug 12, 2015, at 7:12 AM, Gonzalo BG <gonzalobg88@gmail.com> wrote:
> 
> 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. 
> 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:  
> Three cases come to mind:
> 
> - "return {...}; into a std::tuple"
> - constexpr invoke
> - std::bitset::const_reference
> 
> 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. \
>  
> 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).  
> Does libc++ has a policy with respect to extensions?
> 
> If so, what is this policy?

IMO, libc++ should follow the clang policy on extensions:
http://clang.llvm.org/get_involved.html <http://clang.llvm.org/get_involved.html>

-Chris

[Attachment #5 (unknown)]

<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 &lt;<a \
href="mailto:gonzalobg88@gmail.com" class="">gonzalobg88@gmail.com</a>&gt; \
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:&nbsp;</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.&nbsp;</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).&nbsp;</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>

[Attachment #6 (text/plain)]

_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

[prev in list] [next in list] [prev in thread] [next in thread] 