220 39052 <67f9b892-ea8d-43ab-aa42-9e225bcbbbac@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr! or constexpr(true) Date: Tue, 10 Jul 2018 04:54:34 -0700 (PDT) Lines: 209 Approved: news@gmane.org Message-ID: <67f9b892-ea8d-43ab-aa42-9e225bcbbbac@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_80998_32369715.1531223674173" X-Trace: blaine.gmane.org 1531223550 23319 195.159.176.226 (10 Jul 2018 11:52:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jul 2018 11:52:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBB654SLNAKGQEWKUIHFQ@isocpp.org Tue Jul 10 13:52:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fcrBx-0005wm-7r for gclcip-std-proposals@m.gmane.org; Tue, 10 Jul 2018 13:52:25 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id g6-v6sf21978104ybc.5 for ; Tue, 10 Jul 2018 04:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=OPsyQt4tO+rGy9F6JU+o1ho3NWvbu75JNi2AvbZZyR0=; b=IQIHcxbYmk8fPiGfnTpqylwiucolwGaTibkK0decSUC5XdU/gOEw+7VjBiUDJDJ/kg AELD1cvtwOyrHjZVN3/ecZief6LunDOBoQ/ofdQmvC30qM+0YxXFKD1o1Q5OHzHjRQ51 xdoWuaZyR0Nso5o/e4mITTJ7Xg+nGbL2X4gOWrgA+1l4uD7lciXloGTxu9+pvYPQ242t q68KGhKveOD2+/5chZagPXmWwHjnvX6B5uQepjv65NhtBmLi0JJZIAvrEB9kY19/rZb6 BYaNwkTeD+qyI0v5ieFIRIzHXJAcW/HOmDLFMRSiy++oTsuvPidr4mc31mUOZHeN/7se tEeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=OPsyQt4tO+rGy9F6JU+o1ho3NWvbu75JNi2AvbZZyR0=; b=c7QG1djQ/oNmsOchJ0RWnU1HIYMtOWctCXk18Id8mpzRksrEHMVx8cLYIIq08aLMln AGZjxmjcLInAxEXUXxH1ADrh9Hc0iokFRSvDt2bWEaO8RX+XazQ+Lo6K/GYX15a/fZ+6 Rc/ilg7c1vSA53/Oj2BVs/3Ov6HD3nBgGIh6Au9MUpkzm/XqGtXpph/0RwV5tG0SzheP wMTzH/Jo0N64ZQpKPdagjCuL2Ix0D6CxLQ5fgdamFdQLm4qtiOTI8LiP1c+ijGUcMqqJ qR/yE+UM9d0r9E+FzbLeDFL+PHLkq/QifdHaCNY2f5P71zHXxjehZh5Pc6MnzlUNFz3N xDyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=OPsyQt4tO+rGy9F6JU+o1ho3NWvbu75JNi2AvbZZyR0=; b=Sk02cTYbrJenEPbz2shLfsAvTSTuipvsKpMrI6evKbQrc96x0zX5PHubwxT4W8Yt2F xll5COyZ3pdnIUFFkP5qpXwNHGyYR3DjxrT0Xta300Lb6mpRoIK/Cy5LF2o0RKdQd/3j kxIUsCrXfB21HfjJfW2IX1MywJjVnelD3l4jCQg3GaM0grZYuDtrpGLuEoM0LuGpBEqz faLcY2CMdyTpL2LAnuxjFEOKmDiVHCvLtupj58MCejZXQjAaqKG9UTNbJDxOy5pC7Zn1 4dk8IfXm5C9WjWhhixjHLVN7wNmmBVLq/JAv7sR9MUNl+I5S8/B8nrSgTfjz0CefjV+/ w60A== X-Gm-Message-State: APt69E0fhKK3Vk9qad5/JVW+ea1ug6qXf+wIVQS2Q5YcrduHoPGSOpMa 8idkboVP4L/4Hl5R6WZot9saoA== X-Google-Smtp-Source: AAOMgpdlApliHegXkJ7Plnywt25nTLmhxE94Yyatinz5C4czOvPZZ4XbYqx0bqhczE3psyubldke+A== X-Received: by 2002:a25:8686:: with SMTP id z6-v6mr7374565ybk.37.1531223676080; Tue, 10 Jul 2018 04:54:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:3881:: with SMTP id f123-v6ls4654486yba.16.gmail; Tue, 10 Jul 2018 04:54:35 -0700 (PDT) X-Received: by 2002:a25:8486:: with SMTP id v6-v6mr3390803ybk.3.1531223674655; Tue, 10 Jul 2018 04:54:34 -0700 (PDT) In-Reply-To: X-Original-Sender: gmisocpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:39052 Archived-At: ------=_Part_80998_32369715.1531223674173 Content-Type: multipart/alternative; boundary="----=_Part_80999_500634995.1531223674173" ------=_Part_80999_500634995.1531223674173 Content-Type: text/plain; charset="UTF-8" On Tuesday, July 10, 2018 at 7:06:43 PM UTC+12, Richard Hodges wrote: > > > > On Tue, 10 Jul 2018 at 02:04, > wrote: > >> Hello everyone >> >> Have the authors of p10731r.html considered if this suggestion: >> >> constexpr(true) int sqr(int n) { >> return n*n; >> } >> >> is preferable and more consistent or flexible than this which they >> currently propose: >> >> constexpr! int sqr(int n) { >> return n*n; >> } >> >> And would it offer the following possibility and would it be useful?: >> >> constexpr(some_condition()) int sqr(int n) { // constexpr this >> function on certain conditions. >> return n*n; >> } >> >> Also many compilers support forceinline functionality etc. Perhaps this >> should be standardized too now? >> Therefore I think the authors might want to propose this too: >> >> inline(false) int sqr(int n) { // force inline. Or inline! if the >> committee thinks best. >> return n*n; >> } >> >> Which might similarly allow this?: >> inline(some_other_condiition()) int sqr(int n) { // force inline. Or >> inline! if the committee thinks best. >> return n*n; >> } >> >> where some_other_condition might test for a certain platform or compile >> where forcing inline or not might be desirable despite what the compiler >> thinks. >> >> It seems to me using ! is a little unusual syntax and be less consistent >> and flexible than what I'm proposing but I admit ! is shorter. >> >> I see such macros regarding forceinline in various code bases such as >> libcxx's __config file. So perhaps forceinline's time has come too. >> >> What do the authors of p1073r1 and others think? >> > > What one of the others thinks: > > a) The exclamation mark on the end is revolting, adding nothing to the > syntax. > > b) Do you have a compelling, motivating use case in mind? By this I mean a > real one, not just "we ought to have it because it seems consistent". > > I ask for b) because I am strongly of the view that code should express > intent, which the compiler then turns into action. What is the "intent" of > writing: > > constexpr(some_test()) int sqr(int n); > > ? > > What could some_test() possibly be testing? Why would it matter? The > implementation of sqr is either a constexpr expression or it's not. If it > is, its constexpr-ness can be undone by the context of its use (because it > takes an argument). What's wrong with that? > > > The main motivation for my post was I wasn't hot for the ! syntax in constexpr!. constexpr(true) seems more c++-ish to me. I can't myself see any reason to want to conditionally constexpr some function but the non ! syntax doesn't shut any doors if people later did find a use case. I wouldn't be desperately unhappy with constexpr! though. But I'd like to see inline get the same treatment. So we get __forceinline standardized and it seems it should be consistent with the constexpr syntax, There I can imagine inline(some_test()) int sqr(int n); might be more useful, but I'm not sure. some_test() might return a different value based on some compilers ability to inline in a desirable way or not. But even there in reality I imagine people will #if different functions anyway if that was the case. __forceline being standardized as inline(true) or inline! is the main thing. And if there was a use for inline(some_condition()) then it seems constexpr(true) would be the better syntax to match it even if no real expression is supported. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%40isocpp.org. ------=_Part_80999_500634995.1531223674173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tuesday, July 10, 2018 at 7:06:43 PM UTC+12, Ri= chard Hodges wrote:


On Tue, 10 Jul 2018 at 02:04, <= ;gmi= s...@gmail.com> wrote:
Hello e= veryone

Have the authors of=C2=A0p10731r.html considered if t= his suggestion:

constexpr(true) int sqr(int n) {
= =C2=A0 return n*n;
}


is preferable and more consi= stent or flexible than this which=C2=A0they currently propose:
constexpr! int sqr(int n) {
=C2=A0 return n*n;
}

And would=C2=A0it offer=C2=A0the following=C2=A0possibili= ty and would it be useful?:

constexpr(some_conditi= on()) int sqr(int n) { //=C2=A0constexpr this function=C2=A0on certain=C2= =A0conditions.
=C2=A0 return n*n;
}

Also=C2=A0many comp= ilers support=C2=A0forceinline functionality etc. Perhaps this should be st= andardized too now?
Therefore I think the authors might want to= =C2=A0propose this too:

inline(false) int sqr(int = n) { // force inline. Or inline! if the committee thinks best.
=C2=A0 re= turn n*n;
}

Which might similarly allow this?:<= /div>
inline(some_other_condiition()) int sqr(int n) { // force in= line. Or inline! if the committee thinks best.
=C2=A0 return n*n;
}

where some_other_condition might=C2=A0test for a ce= rtain platform or compile where forcing inline or not might be desirable de= spite what the compiler thinks.

It seems to me usi= ng ! is a little unusual syntax=C2=A0and be less consistent and flexible th= an what I'm proposing but=C2=A0I admit ! is shorter.
I see such macros regarding forceinline in various code bases s= uch as libcxx's __config file. So perhaps forceinline's time has co= me too.

What do the authors of=C2=A0p1073r1 = and others think?

W= hat one of the others thinks:

a) The exclamation m= ark on the end is revolting, adding nothing to the syntax.

b) Do you have a compelling, motivating use case in mind? By this = I mean a real one, not just "we ought to have it because it seems cons= istent".

I ask for b) because I am strongly o= f the view that code should express intent, which the compiler then turns i= nto action. What is the "intent" of writing:

=
constexpr(some_test()) int sqr(int= n);=C2=A0

?

What = could some_test() possibly be testing? Why would it matter? The implementat= ion of sqr is either a constexpr expression or it's not. If it is, its = constexpr-ness can be undone by the context of its use (because it takes an= argument). What's wrong with that?


=

The main motivation=C2=A0= for my post was=C2=A0I=C2=A0wasn't hot for=C2=A0the !=C2=A0syntax=C2=A0= in constexpr!.=C2=A0constexpr(true) seems more c++-ish to me.
I c= an't myself see any reason to want to conditionally constexpr some func= tion but the non ! syntax doesn't shut any doors=C2=A0if=C2=A0people la= ter did find a use case.
I wouldn't be desperately unhappy wi= th constexpr! though.

But I'd like to se= e inline get the same treatment. So we get=C2=A0__forceinline standardized = and it seems it should be consistent with the constexpr syntax,
T= here I can imagine inline(some_test()) = int sqr(int n);=C2=A0might be more useful, but I'm not sure.
some_test() might return a different value based=C2=A0on some compil= ers=C2=A0ability to inline in a desirable way or not.
But even th= ere in reality I imagine people will #if different functions anyway if that= was the case.

__forceline being standardized as i= nline(true) or inline! is the main thing.
And=C2=A0if there was a= use for inline(some_condition()) then it seems constexpr(true) would be th= e better syntax to match it even if no real expression is supported.
<= 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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/67f9b892-ea8d-43ab-aa42-9e225bcbbbac= %40isocpp.org.
------=_Part_80999_500634995.1531223674173-- ------=_Part_80998_32369715.1531223674173-- .