220 39054 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicolas Lesser Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr! or constexpr(true) Date: Tue, 10 Jul 2018 13:59:40 +0200 Lines: 265 Approved: news@gmane.org Message-ID: References: <67f9b892-ea8d-43ab-aa42-9e225bcbbbac@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000fd6fc0570a3deec" X-Trace: blaine.gmane.org 1531223869 12831 195.159.176.226 (10 Jul 2018 11:57:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jul 2018 11:57:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDXKNLEUTADRBN57SLNAKGQEPVWS2RQ@isocpp.org Tue Jul 10 13:57:45 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fcrH3-0003AJ-Mc for gclcip-std-proposals@m.gmane.org; Tue, 10 Jul 2018 13:57:41 +0200 Original-Received: by mail-oi0-f70.google.com with SMTP id s200-v6sf29919430oie.6 for ; Tue, 10 Jul 2018 04:59:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1531223992; cv=pass; d=google.com; s=arc-20160816; b=iZt3cKKgnL+I1aCWjcs45UkkHPPPxb0aRGL1H4dIRwvkHpdM8vXgWwqTmDXibe35ca FnixUK3fGEmU/WQv8aVRXS/y2BuF7jvZqo2UjgkhAiuiUEfZ6hJNePCJPn9IYIL0YVhR SoYXk1Zn80IS8JzLgt051kCq/IdC7A6geZrM26LuwKrIV9RBDiSgn+jv50OVnEiwj0wS aybjQE0Nr+eyD8o23yd4v/1MreaLyy0t3LM6DMs1U3TZmiBGqfbCO19phRbUw85cQ4QS OgQw28ODBxBW2yk2P2L0BJu/AYqQPxftiB9K3E5daP0QSj3qfDnEq2gVSj3hgrGeikSe JAQg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=/44vKjuYJ/JkfbsUvWxPbfDqhJro/tL34PLP7dkvFLQ=; b=SWL8jrqRKb7xDR2wdBo798dwvA/Nx1nKaaQGH0GVkl6PvavBOnrVQLoN11GBVDes2O nwHJgGtH+PbtkuEkFXUC1qrpRhb/zCxC26wlPfsGIalMXNOzgEPffLDHzqWytWOs2w7E 9aLEmbtB5b/jUYAq4cCYv4Qx4KJv+Q2QPKhBkDh2D+SIjIRBdxG1FAXdjABJR8NBn9S7 amIU3o/QGIKaqvmH8O21oq235QOuCsnlwyo4GNOzZhRVFHWL79FNyAaVyB0QWgRc0M4q MfQilQjvfy+mbUKoZ2TJ3lj35czQcmzqi2VBSkSSXZ2ZqepxYTOL2ESrrpRe6/gfqInX kx5g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="NZF/zLrC"; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=/44vKjuYJ/JkfbsUvWxPbfDqhJro/tL34PLP7dkvFLQ=; b=MK0uqdlxOFqhddELfbjXzxbF+6oYCo4zFqFE+Y6QO9Y/Co3693x3qjOqQiY98HjMCE lcx8KanoO/UdphdJVGqujb1k8DLFPQRQzOmp8DcqL8lCNK7EO+LeACADuJQMkf9k7gmp eokeWWR/FvG8dTfqakkgmanjL5laWdFiE1M/PC5euJjCal0XtM9xiO/rDRCSAqfuuChR UsmNc5Gr+/ahEM57u4z00n8vCCAXJay9yQ4iTfrC30Obv/pAJO/ZIo8dt14Gareo/i8L 8RKS+LV1r8cGaSqYsT8oKLXjYU0PTxYHKqCSNK26Odbe0K7JyqkNPmAQte2xI+2CTT7P pZYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=/44vKjuYJ/JkfbsUvWxPbfDqhJro/tL34PLP7dkvFLQ=; b=am2rzyFEzxbxeEUqvA9B7MBXLAxtvyrjDHqOV3MIXDFTcpXNjLlVBciZIr4WDZnQtP GxUbT6jmyAHvxMMVfIHnvxRmuj2ZfhzJ2/TCFf0sn+686sdazwY4VwKcaEb5axruFAi+ BxGKNecSOwha9LTobhTg662sL1gYRAguY9DnbXp9ZGw5Jg1UAt8GRmL4G5s8lJwk4q/U xDwwz8mXf3cw1nPc8rYQIStdi2Ficguw9CyYG852ChBVUoufn9vDg0PR30c7EerwdYzi 9xi2kNYjk25ibbO71y5Ys12fHPHG29k9YYWq75FF3t8GXpSmOk4ADv8gvslu7Xu/fXve gO1g== X-Gm-Message-State: APt69E0JrXrCB3aESwIEmwRxU2/twpJO0OE64EuAnFH9Hh6NUa7sGdSP nFyz3FjP3+0Ulg4Ewx9ldv+l4A== X-Google-Smtp-Source: AAOMgpeqegOdVZIJ7GiD3qtoFTKctG6uJGlNe7/XGy8CcochxQp5GA3n5G3y+FFT5ArHj+RBxPXX5Q== X-Received: by 2002:aca:6146:: with SMTP id v67-v6mr3268198oib.108.1531223992649; Tue, 10 Jul 2018 04:59:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aca:37d4:: with SMTP id e203-v6ls9752000oia.5.gmail; Tue, 10 Jul 2018 04:59:51 -0700 (PDT) X-Received: by 2002:aca:f2c3:: with SMTP id q186-v6mr1149300oih.193.1531223991651; Tue, 10 Jul 2018 04:59:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531223991; cv=none; d=google.com; s=arc-20160816; b=ogOAYZ/KfLffWQ7bCIT1WtR0Gp1Yo1IKXyOnL/4TqPjBrQL/79qjUis30lfH1ynsgA dOyzom5Glo4/JmiqdKK7WYGm2yNghq/FHlCMAToAZpWAyMwVjg+aaKf/aRUxP/Glf75R Qf864sBLdYCXo20DyRVWtxxRziLqhuBFkvD9vueOtSdw3ge0I1LKif7wVvcS8XFfzouS i56dZ0JHgYr38/brN8531wPjr/ojFc5KY+HDg7ogrZOTCrOTL7iqED3brydKQVkkEGpv a+t9XqLNr2kuN9PTTFVO+2CpDg/jinlmnHWqQMEXBeBg4auMpkcscSGpjwL0yj9EVF95 YrOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=571pJlM8T52/FJjF/OoKbyefzS/0Ty+EDynmnmwztGk=; b=vMKgqiRR5E8vzuSInuDtrgqkG8Q6emIArm+bT8Xn7DuBUzo/RJPRrEEoYjbweOrtjW RgFqkuM4lop04jeTy8MRBYjbIof789zowDD/sD9SOOwzaf6ey3C/B/4QqfiLUURpNL7m dv1AMZ1zwDY06BEJiw6T1BX4UT1vhFNA7lhIebNVusGLz2FcJ2paF5A5c5egvW+qmbNC XinHc49vQMfZlZZgNKfWiBrgSUPRkB1fzjvHuDLKB4kucN5ehBRkdPuCVAY2ZSQvMGhK 6mvu4z8NGASOtqbXvyaqddiSMsjrXoA4Pobks/LvyT0142I7DfNPjf89Ya4Yo6QbFtR8 ngHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="NZF/zLrC"; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id p67-v6sor11598317oib.308.2018.07.10.04.59.51 for (Google Transport Security); Tue, 10 Jul 2018 04:59:51 -0700 (PDT) Received-SPF: pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:aca:2cce:: with SMTP id s197-v6mr26129493ois.125.1531223991111; Tue, 10 Jul 2018 04:59:51 -0700 (PDT) In-Reply-To: <67f9b892-ea8d-43ab-aa42-9e225bcbbbac@isocpp.org> X-Original-Sender: blitzrakete@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="NZF/zLrC"; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:39054 Archived-At: --0000000000000fd6fc0570a3deec Content-Type: text/plain; charset="UTF-8" I don't like this syntax because it is too similar to the noexcept operator and explicit bool, while being too dissimilar to the effects of those two. If I read constexpr(true) I would assume that the function is simply constexpr, not some more strict version of constexpr. Similarly, I'd expect to write constexpr(f()) so that depending on f, mit function is constexpr or not. But this is not what is happening, and what I expect to happen is already possible. I also don't see the motivation of inline(true) for the same reasons. Additionally, forced inline is rarely needed and I don't think we should standardize it, because it would require novel syntax for no real benefit. Yes, it is useful, but only rarely. But that's just my opinion. On Tue, Jul 10, 2018, 1:54 PM wrote: > > > 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 > > . > -- 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/CALmDwq2fJ2_tUJa13BWkOACnHqDqJM2q8Bfct2TqCyvsKnDLRg%40mail.gmail.com. --0000000000000fd6fc0570a3deec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't like this syntax because it is too similar to= the noexcept operator and explicit bool, while being too dissimilar to the= effects of those two.

If I re= ad constexpr(true) I would assume that the function is simply constexpr, no= t some more strict version of constexpr. Similarly, I'd expect to write= constexpr(f()) so that depending on f, mit function is constexpr or not. B= ut this is not what is happening, and what I expect to happen is already po= ssible.

I also don't= see the motivation of inline(true) for the same reasons. Additionally, for= ced inline is rarely needed and I don't think we should standardize it,= because it would require novel syntax for no real benefit. Yes, it is usef= ul, but only rarely.

But= that's just my opinion.

On Tue, Jul 10, 2018, 1:54 PM <gmisocpp@gmail.com> wrote:


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


On Tue, 10 Jul 2018 at 02:04, <<= a rel=3D"nofollow noreferrer">gmis...@gmail.com> wrote:
Hello everyone

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

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


is pref= erable and more consistent or flexible than this which=C2=A0they currently = propose:

constexpr! int sqr(int n) {
=C2=A0 ret= urn n*n;
}

And would=C2=A0it offer=C2=A0the fol= lowing=C2=A0possibility and would it be useful?:

c= onstexpr(some_condition()) int sqr(int n) { //=C2=A0constexpr this function= =C2=A0on certain=C2=A0conditions.
=C2=A0 return n*n;
}

= Also=C2=A0many compilers support=C2=A0forceinline functionality etc. Perhap= s this should be standardized too now?
Therefore I think the auth= ors might want to=C2=A0propose this too:

inline(fa= lse) int sqr(int n) { // force inline. Or inline! if the committee thinks b= est.
=C2=A0 return n*n;
}

Which might simila= rly allow this?:
inline(some_other_condiition()) int sqr(int n) {= // force inline. Or inline! if the committee thinks best.
=C2=A0 return= n*n;
}

where some_other_condition might=C2=A0t= est for a certain platform or compile where forcing inline or not might be = desirable despite what the compiler thinks.

It see= ms to me using ! is a little unusual syntax=C2=A0and be less consistent and= flexible than what I'm proposing but=C2=A0I admit ! is shorter.
<= div>

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= =C2=A0p1073r1 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 compile= r then turns into action. What is the "intent" of writing:
<= div>
constexpr(some_test(= )) int sqr(int n);=C2=A0

?

What could some_test() possibly be testing? Why would it matter? T= he 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 (becau= se it takes an argument). What's wrong with that?

<= div>

The main mo= tivation=C2=A0for my post was=C2=A0I=C2=A0wasn't hot for=C2=A0the !=C2= =A0syntax=C2=A0in constexpr!.=C2=A0constexpr(true) seems more c++-ish to me= ..
I can't myself see any reason to want to conditionally cons= texpr some function but the non ! syntax doesn't shut any doors=C2=A0if= =C2=A0people later did find a use case.
I wouldn't be despera= tely unhappy with constexpr! though.

But I&#= 39;d like to see inline get the same treatment. So we get=C2=A0__forceinlin= e standardized and it seems it should be consistent with the constexpr synt= ax,
There I can imagine inlin= e(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 compilers=C2=A0ability to inline in a desirable way or not.
But even there in reality I imagine people will #if different functio= ns anyway if that was the case.

__forceline being = standardized as inline(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 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 &= 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-propo= sals/67f9b892-ea8d-43ab-aa42-9e225bcbbbac%40isocpp.org.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2fJ2_tUJa1= 3BWkOACnHqDqJM2q8Bfct2TqCyvsKnDLRg%40mail.gmail.com.
--0000000000000fd6fc0570a3deec-- .