220 15235 <16df9eb7-5793-40b1-96c5-f98cd6ffcb7f@isocpp.org> article Path: news.gmane.org!not-for-mail From: sasho648 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Some constexpr changes. Date: Tue, 23 Dec 2014 10:01:55 -0800 (PST) Lines: 502 Approved: news@gmane.org Message-ID: <16df9eb7-5793-40b1-96c5-f98cd6ffcb7f@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3693_699752999.1419357715042" X-Trace: ger.gmane.org 1419357723 19805 80.91.229.3 (23 Dec 2014 18:02:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Dec 2014 18:02:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBNZXHN2QPRBE6442SAKGQEGAX6TVA@isocpp.org Tue Dec 23 19:01:57 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y3TmO-0004iV-MD for gclcip-std-proposals@m.gmane.org; Tue, 23 Dec 2014 19:01:57 +0100 Original-Received: by mail-ob0-f200.google.com with SMTP id gq1sf182698022obb.3 for ; Tue, 23 Dec 2014 10:01:55 -0800 (PST) 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:in-reply-to:references :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=eJ7WSRvu8d6AWeixMpaRFFhyOqh7Vzfz87VnSTHwLhs=; b=Y+hFYs1lwp4uqV1ZLnPfKTRgFgBd0NOc2MNd11020dgTmQztDP+GSTDdxwC8KkRWpp qPZSsAsplz4m7kWYiR/dJLwASx1aTIF7Ou+eDm2AhL/GoS/6/7yGOOOCCGmjRrWq8k8C LmWgcTDq6QkMviBCPwWsIcH9yp/0FY06DyC9TfZsL2uGDhjbKeE9hkfr1MGo2WMy+Jku r02dHa/8DPCNolHcZYLP9HlLelHrc0ItgnwS13T42omqt/3iMTzge8q6VotcL1yP9Ekf Qcy1qNfp9Tz5exKdetW8XUcGuHb6csVGQOcq0l2HJ/odKfv12greOCPWItQ9cbEfeR/X Tu7g== X-Gm-Message-State: ALoCoQn3u3PM43N7yDmBuGpdBPTng2/gwBU6LYcuRUI1q7ZMo63lhNiPEcKaxkrzlY1oceXD6zXb X-Received: by 10.182.81.74 with SMTP id y10mr23810211obx.22.1419357715928; Tue, 23 Dec 2014 10:01:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.98.97 with SMTP id n88ls3634924qge.71.gmail; Tue, 23 Dec 2014 10:01:55 -0800 (PST) X-Received: by 10.140.31.134 with SMTP id f6mr18561qgf.33.1419357715384; Tue, 23 Dec 2014 10:01:55 -0800 (PST) In-Reply-To: X-Original-Sender: sasho648@mail.bg 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:15235 Archived-At: ------=_Part_3693_699752999.1419357715042 Content-Type: multipart/alternative; boundary="----=_Part_3694_1128203221.1419357715042" ------=_Part_3694_1128203221.1419357715042 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 23 =D0=B4=D0=B5=D0=BA=D0=B5=D0=BC=D0=B2=D1=80=D0=B8 2014, =D0=B2=D1=82=D0= =BE=D1=80=D0=BD=D0=B8=D0=BA, 19:23:54 UTC+2, Ville Voutilainen =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0: > > On 23 December 2014 at 17:00, sasho648 >=20 > wrote:=20 > > I decided to change some of my suggestions.=20 > >=20 > >=20 > > First 'constexpr' will be both function-specifier and a variable one.= =20 > > Functions which are 'constexpr' should be evaluated at compile-time.=20 > This=20 > > change reflects my second example:=20 > >=20 > >=20 > > constexpr int FuncAdd(int a, int b) //function declared as constexpr,= =20 > return=20 > > type is 'int'=20 > > {=20 > > return a + b; //is the expression constant or not is defined by ho= w=20 > the=20 > > compiler would assess arguments 'a' & 'b'=20 > > }=20 > >=20 > >=20 > > cout << FuncAdd(9, 8) << endl; //ok, literals '9' & '8' are always=20 > constant=20 > > expression, so the return value is=20 > >=20 > > int *pa;=20 > >=20 > > cout << FuncAdd(*pa, 8) << endl; //ok, returned value of 'FuncAdd' is= =20 > > assessed as non-constant expression=20 > > How does this part change anything from the status quo?=20 > > >=20 > > And adds new ones:=20 > >=20 > >=20 > > auto constexpr FuncAdd(constexpr int a, constexpr int b) -> constexpr= =20 > int=20 > > //function declared as constexpr, return type is 'constexpr int'=20 > > {=20 > return a + b; //this expression will always be constexpr=20 > > }=20 > >=20 > >=20 > > cout << FuncAdd(9, 8) << endl; //ok, literals '9' & '8' are constant=20 > > expression=20 > >=20 > > int *pa;=20 > >=20 > > cout << FuncAdd(*pa, 8) << endl; //error, '*pa' is not a constant=20 > expression=20 > > I don't think it's an accident that=20 > 1) constexpr functions by design can be evaluated with runtime values, so= =20 > it=20 > would be interesting to know the views of the designers of constexpr=20 > in this area=20 > 2) it's also no accident that implementations are not required to=20 > evaluate constexpr=20 > functions at translation time, so similarly the original designers'=20 > views would be interesting.=20 > > > > I'm also suggesting the keyword 'explicit', being placed after a=20 > 'constexpr'=20 > > function declaration, to be allowed and to specify that the function=20 > > shouldn't produce any run-time code and that it should be executed all= =20 > in=20 > > run-time. Examples:=20 > >=20 > > constexpr int FuncAdd(int a, int b) explicit=20 > > {=20 > > cout << a << " + " << b << " is " << a + b << endl; //should=20 > produce=20 > > error, 'std::ostream::operator<<' is not a an explicit constexpr=20 > function=20 > >=20 > > return a + b;=20 > > }=20 > > How is this different from the constexpr function returning a constexpr= =20 > int?=20 > Also, we know how to do context-sensitive keywords, so reusing explicit= =20 > for such a purpose is not the best of ideas because it's far from clear= =20 > what exactly is supposed to be explicit here.=20 > It's different in that evaluating the function at compile-time wouldn't=20 produce any run-time code. A function can return constant expression and still produces run-time code.= =20 Example: auto constexpr FuncAdd(constexpr int a, constexpr int b) -> constexpr int /= /function=20 declared as constexpr, return type is 'constexpr int' { cout << a << " + " << b << " is " << a + b << endl; return a + b; //this expression will always be constexpr } If we instance the above function like this: FuncAdd(9, 8); It will be roughly equivalent to writing this: cout << 9 << " + " << 8 << " is " << 17 << endl; If we declare the above function with the explicit keyword (or some other= =20 specifier with similar meaning) it will fail to compiler because we are=20 instancing a function that will surely require run-time code (or one which= =20 isn't declared with 'explicit'): auto constexpr FuncAdd(constexpr int a, constexpr int b) explicit ->=20 constexpr int //function declared as constexpr, return type is 'constexpr= =20 int' { cout << a << " + " << b << " is " << a + b << endl; //should produce= =20 error, 'std::ostream::operator<<' is not a an explicit constexpr function return a + b; //this expression will always be constexpr } This will be useful when there is a big hierarchy of const-expression calls= =20 which we want to not to produce any additional run-time code. Yes it will be very nice if constexpr designers comment this idea. EDIT: constexpr int FuncAdd(int a, int b) explicit { return a + b; } *I saw that I forgot the 'explicit' keyword in the above example.* --=20 ---=20 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 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-proposa= ls/. ------=_Part_3694_1128203221.1419357715042 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


23 =D0=B4=D0=B5=D0=BA=D0=B5=D0=BC=D0=B2=D1=80=D0= =B8 2014, =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 19:23:54 UTC+2, Ville= Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
On 23 December 2014 at 17:00, sasho648 <sash...@mail.bg> wrote:
> I decided to change some of my suggestions.
>
>
> First 'constexpr' will be both function-specifier and a variable o= ne.
> Functions which are 'constexpr' should be evaluated at compile-tim= e. This
> change reflects my second example:
>
>
> constexpr int FuncAdd(int a, int b) //function declared as constex= pr, return
> type is 'int'
> {
>      return a + b; //is the expression constant or = not is defined by how the
> compiler would assess arguments 'a' & 'b'
> }
>
>
> cout << FuncAdd(9, 8) << endl; //ok, literals '9' &= ; '8' are always constant
> expression, so the return value is
>
> int *pa;
>
> cout << FuncAdd(*pa, 8) << endl; //ok, returned value = of 'FuncAdd' is
> assessed as non-constant expression

How does this part change anything from the status quo?

>
> And adds new ones:
>
>
> auto constexpr FuncAdd(constexpr int a, constexpr int b) -> con= stexpr int
> //function declared as constexpr, return type is 'constexpr int'
> { 
&= gt;      return a + b; //this expression will always be cons= texpr
> }
>
>
> cout << FuncAdd(9, 8) << endl; //ok, literals '9' &= ; '8' are constant
> expression
>
> int *pa;
>
> cout << FuncAdd(*pa, 8) << endl; //error, '*pa' is not= a constant expression

I don't think it's an accident that
1) constexpr functions by design can be evaluated with runtime values, = so it
would be interesting to know the views of the designers of constexpr
in this area
2) it's also no accident that implementations are not required to
evaluate constexpr
functions at translation time, so similarly the original designers'
views would be interesting.


> I'm also suggesting the keyword 'explicit', being placed after a '= constexpr'
> function declaration, to be allowed and to specify that the functi= on
> shouldn't produce any run-time code and that it should be executed= all in
> run-time. Examples:
>
> constexpr int FuncAdd(int a, int b) explicit
> {
>      cout << a << " + " << b <= < " is " << a + b << endl; //should produce
> error, 'std::ostream::operator<<' is not a an explicit const= expr function
>
>      return a + b;
> }

How is this different from the constexpr function returning a constexpr= int?
Also, we know how to do context-sensitive keywords, so reusing explicit
for such a purpose is not the best of ideas because it's far from clear
what exactly is supposed to be explicit here.

It's different in that evaluating the = function at compile-time wouldn't produce any run-time code.

=
A function can return constant expression and still produces run= -time code. Example:

auto<= /span> constexpr FuncAdd(constexpr int a, constexp= r <= span style=3D"color: #008;" class=3D"styled-by-prettify">int b) -> constexpr = int //function decla= red as constexpr, return type is 'constexpr int'
{
     cout << a << " + " << b << = " is " << a + b << endl;

     return a + b; = //this expression= will always be constexpr
}

If we instance the above function like this:

FuncAdd(9, 8);

It will be roughly equivalent= to writing this:

cout &l= t;< 9 << " + " << 8 = << " is " << 17 << endl;

If we declare the = above function with the explicit keyword (or some other specifier with simi= lar meaning) it will fail to compiler because we are instancing a function = that will surely require run-time code (or one which isn't declared with 'e= xplicit'):

auto constexpr FuncAdd(constexpr int a, constexpr int b) explicit = -> constexpr int //function declared as constexpr, return type is '= constexpr int'
{<= /span>
  =    cout << a &= lt;< " + "= << b << " is " << a + b= <<<= /span> endl; //should produce error, 'std::ostr= eam::operator<<' is not a an explicit constexpr function

    &= nbsp;retur= n a + b; //this expression will always be constexpr
}

This will be useful when there is a big hierarchy of const-expression= calls which we want to not to produce any additional run-time code.

Yes it will be very nice if constexpr designers comm= ent this idea.

EDIT:

constexpr int FuncAdd(int a, int b) explicit
{
     return a + b;
}
=

I saw that I forgot the 'e= xplicit' keyword in the above example.

--

---
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_3694_1128203221.1419357715042-- ------=_Part_3693_699752999.1419357715042-- .