[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: David Majnemer <david.majnemer () gmail ! com>
Date: 2015-08-12 18:32:43
Message-ID: CAL7bZ_c8122CYsTc2A5g7mHUFOWdw5xGFEp9SJ+WdETZ33gt-Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> 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.
>
Wouldn't we have to be extra careful or we could get ODR violations across
object/shared object boundaries if one wanted extra conformance but another
did not?
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On \
Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <span dir="ltr"><<a \
href="mailto:richard@metafoo.co.uk" \
target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><span class="">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><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></span><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></blockquote><div><br></div><div>Wouldn't we \
have to be extra careful or we could get ODR violations across \
object/shared object boundaries if one wanted extra conformance but another \
did not?</div><div> </div><blockquote class="gmail_quote" style="margin:0 \
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> \
<br>_______________________________________________<br> cfe-dev mailing \
list<br> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" \
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic