220 8057 <8c654488-9a6d-4d14-ae94-c854bf9fcf8b@isocpp.org> article Path: news.gmane.org!not-for-mail From: Mark Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Subsets of constexpr functions should be considered constant expressions (in certain cases) Date: Fri, 6 Dec 2013 20:31:43 -0800 (PST) Lines: 173 Approved: news@gmane.org Message-ID: <8c654488-9a6d-4d14-ae94-c854bf9fcf8b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1191_17579079.1386390703795" X-Trace: ger.gmane.org 1386390702 27893 80.91.229.3 (7 Dec 2013 04:31:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Dec 2013 04:31:42 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC65PPNS7IERBMGJRKKQKGQECIXO5XY@isocpp.org Sat Dec 07 05:31:47 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vp9YP-00088Q-Q3 for gclcip-std-proposals@m.gmane.org; Sat, 07 Dec 2013 05:31:46 +0100 Original-Received: by mail-vc0-f200.google.com with SMTP id hu19sf2956710vcb.11 for ; Fri, 06 Dec 2013 20:31:45 -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:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=BXeJcRbdxhzbFX8EX8rzTWp/lPP0sYeh01cTUGuC444=; b=sPLZ5LUCbT+efzh8TpDaQemZjD5dVmzJIKFwdPUh/XGlcbSe/sgAiDaFdudNLgFPp4 lJXEiiEZkGnLZay9TLQUjmmoh5G3GVkb/wOGz5gtfv8qDhAPunvQ3ezLQnSoAr1Ca9Wx FV1JxxBy5Mleau8LC1bxNcQ+S6zWECr5SeYV3lsi56FKkfRTlLhdq884g7WdVTU4pQMv Ey0j/CdmpBCeUxdW/Veq38VZixv/bziHTFyPSghL7YZgFDR4okQ7jpxXR4iVhOFo4YsW 7OR1WJ2uUfmCQYgSr0EBVVbBPf/PhmcyOy8GeP4o3UoYdY8qbJ/rL/iZnHLdtM+VymHJ Eobg== 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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=BXeJcRbdxhzbFX8EX8rzTWp/lPP0sYeh01cTUGuC444=; b=XCJ2DAbn8isosHwlGM50mrGPkT8wcwxDyWW/o6Y1m9wfEgJ5qknVgh38H/c2QaXNZr Gg+TqYKxWqL4HLYfaiK0wT9v0hquFJsOQ9dhoH/wQzz/NfsZvhhVuX85SqdUxMDGnaM1 TU7mUyBYtY/FdvpxnjllTpwukJvxrJPHEz3B6/TUl+p/20vsPz84c25TVTJvaduYoDKn Bcx+tefz3tvR8Likegt8z5BbUm2Tfb5yQ+KcuNCTWrjULKE0BfnAT1Z026UEn4r9PYQz mY9Zln9iqp+bfFpL29U8tmoLqms/OFD0ZNcFxYhak1vDUahIR3Oxj1VqWIAYwAOentXA zTpg== X-Gm-Message-State: ALoCoQmGTmYgrzBQEor28qeyhvTNoy55+3LZA68hThpLtVKqyVJ8X+7GRRMryjA42A39QjDo50mk X-Received: by 10.58.198.116 with SMTP id jb20mr2512594vec.4.1386390704900; Fri, 06 Dec 2013 20:31:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.222.5 with SMTP id qi5ls443052obc.58.gmail; Fri, 06 Dec 2013 20:31:44 -0800 (PST) X-Received: by 10.182.236.232 with SMTP id ux8mr56113obc.12.1386390704283; Fri, 06 Dec 2013 20:31:44 -0800 (PST) X-Original-Sender: turck11@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:8057 Archived-At: ------=_Part_1191_17579079.1386390703795 Content-Type: text/plain; charset=ISO-8859-1 I've been toying around with the relaxed constexpr rules of C++14 in an SVN build of clang. The thought occurred to me that I might be able to use the 'natural' syntax of a for loop to iterate over the contents in a std::tuple at compile-time in a constexpr function. This seems conceptually plausible, as I am now allowed to loop over a range at compile-time, but as I found out on Stack Overflow, when speaking strict standardese, I cannot instantiate a template (like std::get) with my loop variable because the variable is not constexpr, even though it is part of a constexpr function. A simplified example: template constexpr int foo() { return N; } constexpr int getSum() { auto sum = 0; for (auto i = 0; i < 10; ++i) { sum += foo(); //The interesting part } return sum; } constexpr auto sum = getSum(); I'd like to open discussion as to whether or not it makes sense to allow this. I should also clarify, I understand that constexpr functions can be invoked at runtime. I am not talking about that case; there are already cases where constexpr functions fail to compile only when used for runtime invocations, I would extend that principal to this case. I only propose this relaxation for when a constexpr function is evaluated in a compile-time context. -- --- 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_1191_17579079.1386390703795 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've been toying around with the relaxed constexpr ru= les of C++14 in an SVN build of clang. The thought occurred to me that I mi= ght be able to use the 'natural' syntax of a for loop to iterate over the c= ontents in a std::tuple at compile-time in a constexpr function. This seems= conceptually plausible, as I am now allowed to loop over a range at compil= e-time, but as I found out on Stack Overflow, when speaking strict standardese, I cann= ot instantiate a template (like std::get) with my loop variable because the= variable is not constexpr, even though it is part of a constexpr function.=

A simplified example:
template=
<int N>
constexpr int foo() {
&nb=
sp; return=
 N<=
span style=3D"color: #660;" class=3D"styled-by-prettify">;
}

constexpr int getSum() {
  auto sum =3D 0;
  for (auto i =3D 0; i < 10=
; ++i) {
    sum +=3D foo<i>(); //The interest=
ing part  }=

 =
 return sum;
}

constexpr auto sum =3D getSum(=
);



I'd li= ke to open discussion as to whether or not it makes sense to allow this.


I should also clarify, I = understand that constexpr functions can be invoked at runtime. I am not tal= king about that case; there are already cases where constexpr functions fai= l to compile only when used for runtime invocations, I would extend that pr= incipal to this case. I only propose this relaxation for when a constexpr f= unction is evaluated in a compile-time context.

--
 
---
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-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/<= /a>.
------=_Part_1191_17579079.1386390703795-- .