[libcxx] Policy with respect to language extensions

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[libcxx] Policy with respect to language extensions

Gonzalo BG
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?

Otherwise, should it have one?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Chris Lattner

On Aug 12, 2015, at 7:12 AM, Gonzalo BG <[hidden email]> 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:

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Richard Smith
On Wed, Aug 12, 2015 at 9:17 AM, Chris Lattner <[hidden email]> wrote:

On Aug 12, 2015, at 7:12 AM, Gonzalo BG <[hidden email]> 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:

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. 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

David Majnemer


On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <[hidden email]> wrote:
On Wed, Aug 12, 2015 at 9:17 AM, Chris Lattner <[hidden email]> wrote:

On Aug 12, 2015, at 7:12 AM, Gonzalo BG <[hidden email]> 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:

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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Marshall Clow
On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <[hidden email]> wrote:
On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <[hidden email]> wrote:

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?

 
Yes.

-- Marshall


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Hal Finkel
----- Original Message -----

> From: "Marshall Clow" <[hidden email]>
> To: "David Majnemer" <[hidden email]>
> Cc: "Richard Smith" <[hidden email]>, "clang developer list" <[hidden email]>, "Gonzalo BG"
> <[hidden email]>
> Sent: Wednesday, August 12, 2015 5:05:05 PM
> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
>
> On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
> [hidden email] > wrote:
>
>
> On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
> [hidden email] > wrote:
>
>
>
> 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?
>
> Yes.
>
>
> -- Marshall

Having a macro to control this seems like a recipe for bad things (ODR violation being only one problem).

I think the best we can do at this point is have the compiler issue a warning in pedantic mode. Maybe we could add some kind of extension attribute for this purpose (although we'd need to think carefully about when to actually generate the warning - every time some extension participates in some overload set might be problematic).

 -Hal

>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Bakhvalov, Denis via cfe-dev
On Wed, Aug 12, 2015 at 4:01 PM, Hal Finkel <[hidden email]> wrote:
----- Original Message -----
> From: "Marshall Clow" <[hidden email]>
> To: "David Majnemer" <[hidden email]>
> Cc: "Richard Smith" <[hidden email]>, "clang developer list" <[hidden email]>, "Gonzalo BG"
> <[hidden email]>
> Sent: Wednesday, August 12, 2015 5:05:05 PM
> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
>
> On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
> [hidden email] > wrote:
>
>
> On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
> [hidden email] > wrote:
>
>
>
> 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?
>
> Yes.
>
>
> -- Marshall

Having a macro to control this seems like a recipe for bad things (ODR violation being only one problem).

What sort of actual bad things do you envisage? People will, of course, be able to shoot themselves in the foot by having an inconsistent definition in different translation units, but we don't necessarily need to support that. And it seems like we should be able to avoid this having an ABI impact on sane code.
 
I think the best we can do at this point is have the compiler issue a warning in pedantic mode. Maybe we could add some kind of extension attribute for this purpose (although we'd need to think carefully about when to actually generate the warning - every time some extension participates in some overload set might be problematic).

 -Hal

>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Bakhvalov, Denis via cfe-dev
----- Original Message -----

> From: "Richard Smith" <[hidden email]>
> To: "Hal Finkel" <[hidden email]>
> Cc: "Marshall Clow" <[hidden email]>, "clang developer list" <[hidden email]>, "Gonzalo BG"
> <[hidden email]>, "David Majnemer" <[hidden email]>
> Sent: Wednesday, August 12, 2015 7:09:22 PM
> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
>  
> On Wed, Aug 12, 2015 at 4:01 PM, Hal Finkel < [hidden email] >
> wrote:
>  
> ----- Original Message -----
> > From: "Marshall Clow" < [hidden email] >
> > To: "David Majnemer" < [hidden email] >
> > Cc: "Richard Smith" < [hidden email] >, "clang developer
> > list" < [hidden email] >, "Gonzalo BG"
> > < [hidden email] >
> > Sent: Wednesday, August 12, 2015 5:05:05 PM
> > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
> > extensions
> >
> > On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
> > [hidden email] > wrote:
> >
> >
> > On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
> > [hidden email] > wrote:
> >
> >
> >
> > 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?
> >
> > Yes.
> >
> >
> > -- Marshall
>
> Having a macro to control this seems like a recipe for bad things
> (ODR violation being only one problem).
>
>
>
> What sort of actual bad things do you envisage? People will, of
> course, be able to shoot themselves in the foot by having an
> inconsistent definition in different translation units, but we don't
> necessarily need to support that. And it seems like we should be
> able to avoid this having an ABI impact on sane code.

For these particular extensions, I can't say. However, I tend to find the general technique problematic. The issue generally arises for header-only libraries that define (or undefined) these kinds of macros, causing very odd interactions (because such things don't compose). Tracking down why including one library header breaks some other library header because of conflicting desires to define _XOPEN_SOURCE, _GNU_SOURCE, etc. is annoying. Doing the same for features of the C++ standard library that could affect uses of SFINAE, etc., I suspect, would be especially annoying.

 -Hal

>
> I think the best we can do at this point is have the compiler issue a
> warning in pedantic mode. Maybe we could add some kind of extension
> attribute for this purpose (although we'd need to think carefully
> about when to actually generate the warning - every time some
> extension participates in some overload set might be problematic).
>
> -Hal
>
>
>
> >
> > _______________________________________________
> > cfe-dev mailing list
> > [hidden email]
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Bakhvalov, Denis via cfe-dev
----- Original Message -----

> From: "Hal Finkel via cfe-dev" <[hidden email]>
> To: "Richard Smith" <[hidden email]>
> Cc: "Marshall Clow" <[hidden email]>, "Gonzalo BG" <[hidden email]>, "clang developer list"
> <[hidden email]>
> Sent: Wednesday, August 12, 2015 7:23:30 PM
> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
>
> ----- Original Message -----
> > From: "Richard Smith" <[hidden email]>
> > To: "Hal Finkel" <[hidden email]>
> > Cc: "Marshall Clow" <[hidden email]>, "clang developer list"
> > <[hidden email]>, "Gonzalo BG"
> > <[hidden email]>, "David Majnemer"
> > <[hidden email]>
> > Sent: Wednesday, August 12, 2015 7:09:22 PM
> > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
> > extensions
> >  
> > On Wed, Aug 12, 2015 at 4:01 PM, Hal Finkel < [hidden email] >
> > wrote:
> >  
> > ----- Original Message -----
> > > From: "Marshall Clow" < [hidden email] >
> > > To: "David Majnemer" < [hidden email] >
> > > Cc: "Richard Smith" < [hidden email] >, "clang developer
> > > list" < [hidden email] >, "Gonzalo BG"
> > > < [hidden email] >
> > > Sent: Wednesday, August 12, 2015 5:05:05 PM
> > > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
> > > extensions
> > >
> > > On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
> > > [hidden email] > wrote:
> > >
> > >
> > > On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
> > > [hidden email] > wrote:
> > >
> > >
> > >
> > > 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?
> > >
> > > Yes.
> > >
> > >
> > > -- Marshall
> >
> > Having a macro to control this seems like a recipe for bad things
> > (ODR violation being only one problem).
> >
> >
> >
> > What sort of actual bad things do you envisage? People will, of
> > course, be able to shoot themselves in the foot by having an
> > inconsistent definition in different translation units, but we
> > don't
> > necessarily need to support that. And it seems like we should be
> > able to avoid this having an ABI impact on sane code.

Also, a few questions:

 1. Are these all confirming extensions?

 2. Would this be an opt-in or opt-out macro?

Having thought about this for an additional few minutes, I think the relevant question is: Is there any sane code that would need to turn these things off in order to function properly? If not, then the header-file library issue won't arise in practice, and the macro is likely harmless. If so, it is not good. Regardless, I think being able to issue a warning would be better.

 -Hal

>
> For these particular extensions, I can't say. However, I tend to find
> the general technique problematic. The issue generally arises for
> header-only libraries that define (or undefined) these kinds of
> macros, causing very odd interactions (because such things don't
> compose). Tracking down why including one library header breaks some
> other library header because of conflicting desires to define
> _XOPEN_SOURCE, _GNU_SOURCE, etc. is annoying. Doing the same for
> features of the C++ standard library that could affect uses of
> SFINAE, etc., I suspect, would be especially annoying.
>
>  -Hal
>
> >
> > I think the best we can do at this point is have the compiler issue
> > a
> > warning in pedantic mode. Maybe we could add some kind of extension
> > attribute for this purpose (although we'd need to think carefully
> > about when to actually generate the warning - every time some
> > extension participates in some overload set might be problematic).
> >
> > -Hal
> >
> >
> >
> > >
> > > _______________________________________________
> > > cfe-dev mailing list
> > > [hidden email]
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> >
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Bakhvalov, Denis via cfe-dev
libc++ has an interesting relationship with extensions. Libc++ was
designed as  a C++11 library with C++03 compatibility.
For this reason C++11 extensions are pervasive in C++03 mode. I don't
think it would be possible to provide a strict C++03 compatibility
mode because the
libc++ C++03 internals are so dependent on C++11 library and language
features such as decltype, nullptr, std::unique_ptr, std::move,
std::forward, etc.

For newer C++ dialects it should be *possible* to provide a strict
conformance mode via a switch. Unfortunately every switch added to
libc++ increases the maintenance burden and code complexity. In my
opinion the less switches libc++ has the better.

However unlike C++03 mode, newer libc++ dialects should probably only
provide *conforming* extensions, which should somewhat reduce the need
for a "strict conformance mode". In the coming week I'll be trying
to document all of the current libc++ extensions. Hopefully that will
give us a better understanding of the problem. Please feel free to
send me any libc++ extensions you have noticed beyond the ones already
mentioned.

Anyway I think the best way to make sure your code is portable across
standard libraries then you should test multiple standard libraries.


/Eric

PS. To address the extensions you listed:

1. "return {...}; into a std::tuple" is now standard in C++1Z. It is
still an extensions in C++11 and C++14 but turning it off by default
could break user code. Also I'm not willing to make tuple any more
complex unless the need is great.

2. I'm not sure what your referring to. libc++'s implementation of
std::invoke is not constexpr. I mistakenly made __invoke constexpr a
while back but that change
has been reverted.

3. std::bitset::const_reference seems fairly innocuous and conforming.


On Wed, Aug 12, 2015 at 7:04 PM, Hal Finkel via cfe-dev
<[hidden email]> wrote:

> ----- Original Message -----
>> From: "Hal Finkel via cfe-dev" <[hidden email]>
>> To: "Richard Smith" <[hidden email]>
>> Cc: "Marshall Clow" <[hidden email]>, "Gonzalo BG" <[hidden email]>, "clang developer list"
>> <[hidden email]>
>> Sent: Wednesday, August 12, 2015 7:23:30 PM
>> Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions
>>
>> ----- Original Message -----
>> > From: "Richard Smith" <[hidden email]>
>> > To: "Hal Finkel" <[hidden email]>
>> > Cc: "Marshall Clow" <[hidden email]>, "clang developer list"
>> > <[hidden email]>, "Gonzalo BG"
>> > <[hidden email]>, "David Majnemer"
>> > <[hidden email]>
>> > Sent: Wednesday, August 12, 2015 7:09:22 PM
>> > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
>> > extensions
>> >
>> > On Wed, Aug 12, 2015 at 4:01 PM, Hal Finkel < [hidden email] >
>> > wrote:
>> >
>> > ----- Original Message -----
>> > > From: "Marshall Clow" < [hidden email] >
>> > > To: "David Majnemer" < [hidden email] >
>> > > Cc: "Richard Smith" < [hidden email] >, "clang developer
>> > > list" < [hidden email] >, "Gonzalo BG"
>> > > < [hidden email] >
>> > > Sent: Wednesday, August 12, 2015 5:05:05 PM
>> > > Subject: Re: [cfe-dev] [libcxx] Policy with respect to language
>> > > extensions
>> > >
>> > > On Wed, Aug 12, 2015 at 11:32 AM, David Majnemer <
>> > > [hidden email] > wrote:
>> > >
>> > >
>> > > On Wed, Aug 12, 2015 at 2:05 PM, Richard Smith <
>> > > [hidden email] > wrote:
>> > >
>> > >
>> > >
>> > > 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?
>> > >
>> > > Yes.
>> > >
>> > >
>> > > -- Marshall
>> >
>> > Having a macro to control this seems like a recipe for bad things
>> > (ODR violation being only one problem).
>> >
>> >
>> >
>> > What sort of actual bad things do you envisage? People will, of
>> > course, be able to shoot themselves in the foot by having an
>> > inconsistent definition in different translation units, but we
>> > don't
>> > necessarily need to support that. And it seems like we should be
>> > able to avoid this having an ABI impact on sane code.
>
> Also, a few questions:
>
>  1. Are these all confirming extensions?
>
>  2. Would this be an opt-in or opt-out macro?
>
> Having thought about this for an additional few minutes, I think the relevant question is: Is there any sane code that would need to turn these things off in order to function properly? If not, then the header-file library issue won't arise in practice, and the macro is likely harmless. If so, it is not good. Regardless, I think being able to issue a warning would be better.
>
>  -Hal
>
>>
>> For these particular extensions, I can't say. However, I tend to find
>> the general technique problematic. The issue generally arises for
>> header-only libraries that define (or undefined) these kinds of
>> macros, causing very odd interactions (because such things don't
>> compose). Tracking down why including one library header breaks some
>> other library header because of conflicting desires to define
>> _XOPEN_SOURCE, _GNU_SOURCE, etc. is annoying. Doing the same for
>> features of the C++ standard library that could affect uses of
>> SFINAE, etc., I suspect, would be especially annoying.
>>
>>  -Hal
>>
>> >
>> > I think the best we can do at this point is have the compiler issue
>> > a
>> > warning in pedantic mode. Maybe we could add some kind of extension
>> > attribute for this purpose (although we'd need to think carefully
>> > about when to actually generate the warning - every time some
>> > extension participates in some overload set might be problematic).
>> >
>> > -Hal
>> >
>> >
>> >
>> > >
>> > > _______________________________________________
>> > > cfe-dev mailing list
>> > > [hidden email]
>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> > >
>> >
>> > --
>> > Hal Finkel
>> > Assistant Computational Scientist
>> > Leadership Computing Facility
>> > Argonne National Laboratory
>> >
>> >
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [libcxx] Policy with respect to language extensions

Bakhvalov, Denis via cfe-dev

On Wed, Aug 19, 2015 at 3:35 AM, Eric Fiselier <[hidden email]> wrote:
In my opinion the less switches libc++ has the better.

I agree.

> In the coming week I'll be trying to document all of the current libc++ extensions. 

First, thanks for taking on this! Knowing which extensions there are would already be very helpful.

For me it would be particularly interesting to know which extensions have been proposed 
for standardization (and in which paper). Howard and you mentioned that the "return {...}; into a std::tuple"
extension made it into the standard draft. I think this is a great example of how a libc++ extension
has resulted in a benefit for the many.

Bests,
Gonzalo

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev