[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:       Richard Smith <richard () metafoo ! co ! uk>
Date:       2015-08-12 18:05:15
Message-ID: CAOfiQqkVAUpiEFF9TK-Y_1iLZ7-AXJ42Q=d_6+tQP8m0k97kPA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Wed, Aug 12, 2015 at 9:17 AM, Chris Lattner <clattner@apple.com> wrote:

>
> 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
>

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.

[Attachment #5 (text/html)]

<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">&lt;<a href="mailto:clattner@apple.com" \
target="_blank">clattner@apple.com</a>&gt;</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 &lt;<a href="mailto:gonzalobg88@gmail.com" \
target="_blank">gonzalobg88@gmail.com</a>&gt; wrote:</div><br><div><div \
dir="ltr"><div>In the following I mean by &quot;language extension&quot; 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&#39;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>- &quot;return {...}; into a \
std::tuple&quot;</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 &quot;strictly conforming&quot; (or as close \
as we can reasonably get) mode, controlled by a macro.  </div></div></div></div>


[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]