From cfe-dev Wed Aug 12 16:17:50 2015 From: Chris Lattner Date: Wed, 12 Aug 2015 16:17:50 +0000 To: cfe-dev Subject: Re: [cfe-dev] [libcxx] Policy with respect to language extensions Message-Id: X-MARC-Message: https://marc.info/?l=cfe-dev&m=143939627904679 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7680468825838932647==" --===============7680468825838932647== Content-type: multipart/alternative; boundary="Apple-Mail=_3093D240-0701-4508-8CC7-CD1A1D3ABC43" --Apple-Mail=_3093D240-0701-4508-8CC7-CD1A1D3ABC43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 12, 2015, at 7:12 AM, Gonzalo BG wrote: >=20 > 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. >=20 > 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:=20 >=20 > Three cases come to mind: >=20 > - "return {...}; into a std::tuple" > - constexpr invoke > - std::bitset::const_reference >=20 > 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.=20 >=20 > 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).=20 >=20 > Does libc++ has a policy with respect to extensions? >=20 > If so, what is this policy? IMO, libc++ should follow the clang policy on extensions: http://clang.llvm.org/get_involved.html = -Chris --Apple-Mail=_3093D240-0701-4508-8CC7-CD1A1D3ABC43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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

-Chris

= --Apple-Mail=_3093D240-0701-4508-8CC7-CD1A1D3ABC43-- --===============7680468825838932647== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2ZlLWRldiBt YWlsaW5nIGxpc3QKY2ZlLWRldkBsaXN0cy5sbHZtLm9yZwpodHRwOi8vbGlzdHMubGx2bS5vcmcv Y2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2NmZS1kZXYK --===============7680468825838932647==--