--===============1350162804408507115== Content-Type: multipart/alternative; boundary=bcaec52d52dd9347f1051d210fcb --bcaec52d52dd9347f1051d210fcb Content-Type: text/plain; charset=UTF-8 On Wed, Aug 12, 2015 at 9:17 AM, Chris Lattner wrote: > > On Aug 12, 2015, at 7:12 AM, Gonzalo BG 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. --bcaec52d52dd9347f1051d210fcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, 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" an= ything 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 enab= le/experiment with language extensions silently by default. This has always= resulted into trouble for me:=C2=A0

Three cases c= ome to mind:

- "return {...}; into a std::tup= le"
- constexpr invoke
- std::bitset::const_refere= nce

These extensions make sense, users might expec= t them, and as a consequence it is easy to use these extensions without kno= wing that one is writing non-portable code.=C2=A0

= I like that people experiment and add extensions to libc++ and wish it woul= d be done more often as long as the extensions are always opt-in (e.g. put = behind a macro).=C2=A0

Does libc++ has a policy wi= th respect to extensions?

If so, what is this = policy?

IMO, libc++ sho= uld follow the clang policy on extensions:

I think it wou= ld also be useful to have a "strictly conforming" (or as close as= we can reasonably get) mode, controlled by a macro.=C2=A0
--bcaec52d52dd9347f1051d210fcb-- --===============1350162804408507115== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2ZlLWRldiBt YWlsaW5nIGxpc3QKY2ZlLWRldkBsaXN0cy5sbHZtLm9yZwpodHRwOi8vbGlzdHMubGx2bS5vcmcv Y2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL2NmZS1kZXYK --===============1350162804408507115==--