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

[David Majnemer]

On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Wed, Aug 12, 2015 at 9:17 AM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Aug 12, 2015, at 7:12 AM, Gonzalo BG <gonzalobg88 at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150812/4e9eaf84/attachment.html>