220 10107 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Shouldn't the constexpr variables be treated as static by default? Date: Mon, 31 Mar 2014 00:57:25 -0700 Lines: 198 Approved: news@gmane.org Message-ID: References: <21e34045-b833-4468-a39e-dbf177938012@isocpp.org> <6838b332-f256-45e7-894b-7cba3593d789@isocpp.org> <4271540.MD85hg9ecn@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1136526af72cf904f5e266a2 X-Trace: ger.gmane.org 1396252653 25415 80.91.229.3 (31 Mar 2014 07:57:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2014 07:57:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBZV74SMQKGQEN4HUTVY@isocpp.org Mon Mar 31 09:57:29 2014 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 1WUX5z-0004Hu-8O for gclcip-std-proposals@m.gmane.org; Mon, 31 Mar 2014 09:57:27 +0200 Original-Received: by mail-vc0-f200.google.com with SMTP id lg15sf18631451vcb.7 for ; Mon, 31 Mar 2014 00:57:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from: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:content-type; bh=X6hePxjB6+rcgmtFAUvTgREXBIKJBTiFI1Q3Yf9rVgU=; b=ie2N4MtPet8EuBKw+tE9s/BnDl3JI8dCPEWoeSCnOqb8FkMb2CG7x0SwEJFlCC8OBo j53+7zuTBXAv536eL+lxvrcatAmtVqKVU2C6tet1jC/cqz8p50sS9Rcvb2iqBeB3bSNk O1fLo88I5mFMFU9S6Qv9ejmV4f9a/90NrTegjQ5hzBqj2FOZmNx3BFBGQmlzZpBeDmNG o10Fme3uVyahDnK8cqpqxTtAcVrJ5zGtQ/629Q5fEUcBHlMR+YYMgO5BhvE8TtucdbXB d+CMwfwKaZmh1LMLNcNUPHhfo0gCXL0JxcrhLcWpLN7F76k1BSXVf40Fah+Olg91MvOe iSaw== X-Gm-Message-State: ALoCoQlb18pBUcKLZw7zKvLtwbqYbfUblHRTMmXxiYxH0tIMzodhG1cJyjRi1/iAyttaF5Wbbtm4 X-Received: by 10.58.210.2 with SMTP id mq2mr7675012vec.3.1396252646473; Mon, 31 Mar 2014 00:57:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.85.203 with SMTP id n69ls2288165qgd.96.gmail; Mon, 31 Mar 2014 00:57:25 -0700 (PDT) X-Received: by 10.220.104.210 with SMTP id q18mr22416363vco.9.1396252645830; Mon, 31 Mar 2014 00:57:25 -0700 (PDT) Original-Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [2607:f8b0:400c:c03::22c]) by mx.google.com with ESMTPS id tm8si2842424vdc.98.2014.03.31.00.57.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 00:57:25 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::22c as permitted sender) client-ip=2607:f8b0:400c:c03::22c; Original-Received: by mail-vc0-f172.google.com with SMTP id la4so8126634vcb.3 for ; Mon, 31 Mar 2014 00:57:25 -0700 (PDT) X-Received: by 10.221.34.7 with SMTP id sq7mr22309525vcb.5.1396252645729; Mon, 31 Mar 2014 00:57:25 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.221.12.203 with HTTP; Mon, 31 Mar 2014 00:57:25 -0700 (PDT) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::22c as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:10107 Archived-At: --001a1136526af72cf904f5e266a2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 31, 2014 at 12:47 AM, Mikhail Semenov < mikhailsemenov1957@gmail.com> wrote: > The rules for odr-used in lambda are rather complicated, for a start: > we've got const, static const. > In general , it is recommended to write static constexpr anyway: why writ= e > two words instead of one? > Another point is that it is constant, no matter how you look at it, why > should it be automatic? > > I haven't written a proposal yet, but I meant all the contexts of definin= g > constexpr variables: > top-level, member and local. > These are three very different changes. For top-level variables, 'constexpr' already implies internal linkage (if the variable is not a reference and is not declared with 'extern'), because it gives it a const-qualified type. So I'm not sure that any change is really warranted here. For member variables, 'constexpr' implying 'static' would eliminate a possible evolution route for the language (constexpr non-static data members, whatever that might mean). The win here seems marginal, and it would make code more difficult to read, because it would no longer be obvious which members of a class are static. (thread_local implying static is already pretty bad in this regard.) I'm not sure you'll find consensus for a change here. For local variables (declared 'constexpr' and not 'extern'), there are several compelling advantages. This case seems easiest to argue, and there's even implementation experience -- Clang's default compilation mode treats large, local, constant-enough variables as if they were static. (Here, "constant enough" means basically: a const-qualified type, a constant-foldable initializer, a trivial destructor, and no mutable members.) To my knowledge, only contrived test cases have ever had problems with this behavior. On Monday, March 31, 2014 7:27:34 AM UTC+1, Thiago Macieira wrote: > >> Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey Romer escreveu: >> > Ah, I hadn't noticed the addresses were varying in the static example. >> I >> > grant that this could theoretically be a breaking change, but how much >> real >> > code would be broken? The kinds of things you'd have to do to notice >> the >> > difference seem like things that you'd normally never do with a >> constexpr >> > variable. >> >> I'd say that for anyone who caused the address to be taken, they really >> want >> the current behaviour. So it will break a lot of code. >> >> What's the benefit you were looking for? >> -- >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >> Software Architect - Intel Open Source Technology Center >> PGP/GPG: 0x6EF45358; fingerprint: >> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 >> >> -- > > --- > 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/. > --=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/. --001a1136526af72cf904f5e266a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 31, 2014 at 12:47 AM, Mikhail Semenov <mikhailsemenov19= 57@gmail.com> wrote:
The rules for odr-used= in lambda are rather complicated, for a start: we've got const, static= const.
In general=A0, it is recommended to write static constexpr anyway: why= write two words instead of one?
Another point is that it is cons= tant, no matter how you look at it, why should it be automatic?
=A0
I haven't written a proposal yet, but I=A0meant all the c= ontexts of defining constexpr variables:
top-level, member and lo= cal.

These are three very diffe= rent changes.

For top-level variables, 'constexpr' already im= plies internal linkage (if the variable is not a reference and is not decla= red with 'extern'), because it gives it a const-qualified type. So = I'm not sure that any change is really warranted here.

For member variables, 'constexpr' implying '= ;static' would eliminate a possible evolution route for the language (c= onstexpr non-static data members, whatever that might mean). The win here s= eems marginal, and it would make code more difficult to read, because it wo= uld no longer be obvious which members of a class are static. (thread_local= implying static is already pretty bad in this regard.) I'm not sure yo= u'll find consensus for a change here.

For local variables (declared 'constexpr' and n= ot 'extern'), there are several compelling advantages. This case se= ems easiest to argue, and there's even implementation experience -- Cla= ng's default compilation mode treats large, local, constant-enough vari= ables as if they were static. (Here, "constant enough" means basi= cally: a const-qualified type, a constant-foldable initializer, a trivial d= estructor, and no mutable members.) To my knowledge, only contrived test ca= ses have ever had problems with this behavior.

On Monday, March 31, 2014 7:27:34 AM UTC+1, Thiago Macieira= wrote:
Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey Romer escreveu= :
> Ah, I hadn't noticed the addresses were varying in the static = example. I
> grant that this could theoretically be a breaking change, but how = much real
> code would be broken? The kinds of things you'd have to do to = notice the
> difference seem like things that you'd normally never do with = a constexpr
> variable.

I'd say that for anyone who caused the address to be taken, they re= ally want=20
the current behaviour. So it will break a lot of code.

What's the benefit you were looking for?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0Software Architect - Intel Open Source Technology Center
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--

---
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/gro= up/std-proposals/.

--

---
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>.
--001a1136526af72cf904f5e266a2-- .