220 15605 <5ccd3d6e-859c-4b66-b61c-317b704647f2@isocpp.org> article Path: news.gmane.org!not-for-mail From: rhalbersma@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Library support for relaxed constexpr Date: Mon, 12 Jan 2015 12:56:48 -0800 (PST) Lines: 154 Approved: news@gmane.org Message-ID: <5ccd3d6e-859c-4b66-b61c-317b704647f2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3762_712830513.1421096208584" X-Trace: ger.gmane.org 1421096224 23069 80.91.229.3 (12 Jan 2015 20:57:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2015 20:57:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMYZKMJV4IRBEPK2CSQKGQELISRIWY@isocpp.org Mon Jan 12 21:56:58 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YAm2d-0005uA-2X for gclcip-std-proposals@m.gmane.org; Mon, 12 Jan 2015 21:56:51 +0100 Original-Received: by mail-pa0-f72.google.com with SMTP id kq14sf212588908pab.3 for ; Mon, 12 Jan 2015 12:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=0dH2r3XWzrvsk76xPC8GLPoUZ9aYKpIOgyS4teLmKUk=; b=Qxuz72QYQ0deXbCNox6iXDvgIJs7owRH5God1khqvtpy+n0g3Ygyja1LdLkJ+vR8vZ mh9bJMgepJyonJjAbOt7CON8X1L2mfPtqJrDl9wz/Li6yOHjoMZyBORo5PJUjaPIIvJy ooalE3nFy6ZD6gwvJwoYM+H23DDAsRKh2DNuKHE5JzlMmP/I1D6cfDang8Bq2K2h2xVl kHdekG8Mt6I0NEIkYW4LyxrLcPZ4xYIHo1aMJuSD9+8gj71wWNTFVBx/bx4+ZkbzjMZu 5F2Dw7C0rGeTfKTBeBWGIAp/ll1TAJkbE0Xvoq3UO9lM1ev4WSxU1pZbh+c7MCCBgdCj KxJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=0dH2r3XWzrvsk76xPC8GLPoUZ9aYKpIOgyS4teLmKUk=; b=ROqBrlOlqKXBi8SdhUIWDvTfyZurODa3pNv4yglYh9/zCya7rrdCVxxf/6xSkVwN0C xdSb1hDnjNrf1Bv8gdUXA47AlX7HBITfyhWO7jIDkCnjFp+9eulCvQF5WmQXwLXbCau5 dhtKniBY8QJy5v48seTwC+wRapqJavMi1mS20xcZlv3bMqDXps66W54TvmaULG5CM0sP l3HzLGrP0hZmPIFKeZ6eyZ4wZ1JiL6lBeEX+vcUYTtAR1MTSiQK748TVnAOOGtyTH8Cy bw0KlGKYfS86HEVIisedCOqOSG6LwBqNwztLyBX89/vvOhYQQcQLQzYzDBsBGi1hZ3y+ HA7A== X-Gm-Message-State: ALoCoQkXPS01mXt+bdTiUP8Iyhf17lXK9QtgPGXyHsKamp4uyO8f5DtUXxQrr8L6/ktQi8VFV+Kp X-Received: by 10.66.136.205 with SMTP id qc13mr22668798pab.2.1421096209665; Mon, 12 Jan 2015 12:56:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.17.115 with SMTP id 106ls2911221qgc.57.gmail; Mon, 12 Jan 2015 12:56:48 -0800 (PST) X-Received: by 10.140.18.228 with SMTP id 91mr35442qgf.26.1421096208943; Mon, 12 Jan 2015 12:56:48 -0800 (PST) X-Original-Sender: rhalbersma@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15605 Archived-At: ------=_Part_3762_712830513.1421096208584 Content-Type: multipart/alternative; boundary="----=_Part_3763_1878649025.1421096208584" ------=_Part_3763_1878649025.1421096208584 Content-Type: text/plain; charset=UTF-8 Now that Item 15 of Effective Modern C++ ("use constexpr whenever possible", see e.g. this recent presentation ) has brought C++14 relaxed constexpr into the mainstream, it is perhaps time to introduce this feature into the Standard Library. I write "introduce" rather than "update" because AFAICS, there is currently *zero* usage of relaxed constexpr (e.g. non-const but constexpr member functions) in the current Draft Standard. As a proof of concept, I have written a fully constexpr version of std::array (available from BitBucket ). In order to do so, I also had to transitively add the constexpr keyword to a bunch of other facilities apart from the header (as Scott Meyers writes "constexpr begets constexpr"). - from the header : fill_n, swap_ranges, equal and lexicographical_compare - from the header : reverse_iterator - from the header : swap Here I benefitted from the fact that the new "diamond operators" such as std::less<> already have a constexpr templated application operator. I chose std::array for this exercise because of its relative simplicity and because it nicely complements the new compile-time integer sequence facilities. The only obstacle I encountered was a single dispatch of fill_n that (at least in libc++) delegates to std::memset for which I had no access to the underlying source code. With that caveat, it was a completely straightforward excercise of transitively adding the keyword constexpr. No other code mofications were necessary. I don't claim to have made a full survey of the entire Standard Library, but a I believe a similar exercise is possible for std::complex, std::bitset (apart from the std::string constructors) and almost all the algorithms from and (apart from a few allocating algorithms such as stable_sort, stable_partition and inplace_merge). Of course, constexpr-ifying the standard algorithms would greatly benefit from extra language support as well (constexpr lambdas, some form of heap allocation to allow compile-time std::string). Nevertheless, given the C++14 features, the Standard Library currently feels vastly underpowered to what the core language offers in terms of constexpr. My question is: how does the community and the committee feel about moving a greater part (the majority?) of the Standard Library towards C++14 relaxed constexpr? I am willing to write a proposal along these lines given enough support (or perhaps there are already efforts underway?) -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_3763_1878649025.1421096208584 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now that Item 15 of Effective Modern C++ ("use constexpr whenever possible", see e.g. t= his recent presen= tation) has brought C++14 relaxed constexpr into the mainstream, it is perhaps time to introduce this= feature into the Standard Library. 

I write "intro= duce" rather than "update" because AFAICS, there is currently *zero* usage = of relaxed constexpr (e.g. non= -const but constexpr member fu= nctions) in the current Draft Standard. 

As a proof= of concept, I have written a fully c= onstexpr version of std::array= (available = from BitBucket). In order to do so, I also had to transitively add the = constexpr keyword to a bunch o= f other facilities apart from the header <array> (as= Scott Meyers writes "constexpr begets constexpr"). 
  • from the header <algorit= hm>: fill_n, swap_ranges, equal and lexico= graphical_compare
  • <iterator>: reverse_iterator<= /li>
  • from the header <utility>: swap
Here I benefitted from th= e fact that the new "diamond operators"  such as std::less<> already have a constexpr templated application operator. I chos= e std::array for this exe= rcise because of its relative simplicity and because it nicely complements = the new compile-time integer sequence facilities. 

The only obstacle I encountered was a single dispatch of fill_n that (at least in libc++) delegat= es to std::memset for which I = had no access to the underlying source code. With that caveat, it was a com= pletely straightforward excercise of transitively adding the keyword <= font face=3D"courier new, monospace">constexpr. No other code mofica= tions were necessary.

I don't claim to have made a= full survey of the entire Standard Library, but a I believe a similar exer= cise is possible for std::complex, std::bitset (apart from t= he std::string constructors) a= nd almost all the algorithms from <= ;algorithm> and <numeric= > (apart from a few allocating algorithms such as stable_sort, stable_partition and inp= lace_merge). 

Of course, constexpr-ify= ing the standard algorithms would greatly benefit from extra language suppo= rt as well (constexpr lambdas,= some form of heap allocation to allow compile-time std::string). Nevertheless, given the C++14 features,= the Standard Library currently feels vastly underpowered to what the core = language offers in terms of constexpr= . 

My question is: how does the commun= ity and the committee feel about moving a greater part (the majority?) of t= he Standard Library towards C++14 relaxed constexpr? I am willing to write a proposal along these lines g= iven enough support (or perhaps there are already efforts underway?)
<= div>

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_3763_1878649025.1421096208584-- ------=_Part_3762_712830513.1421096208584-- .