220 5111 article Path: news.gmane.org!not-for-mail From: Jonathan Wakely Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr data member Date: Wed, 19 Jun 2013 10:06:39 -0700 (PDT) Lines: 122 Approved: news@gmane.org Message-ID: References: <300a19dd-8a82-4788-9802-45170480b30a@isocpp.org> <63d90b03-5605-476d-b40b-7ebcee0d3354@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3695_1868215.1371661599764" X-Trace: ger.gmane.org 1371661601 615 80.91.229.3 (19 Jun 2013 17:06:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2013 17:06:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMONUNYS4IRBIGKQ6HAKGQEGTNTOIY@isocpp.org Wed Jun 19 19:06:42 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f197.google.com ([209.85.128.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UpLqD-0007mK-PE for gclcip-std-proposals@m.gmane.org; Wed, 19 Jun 2013 19:06:42 +0200 Original-Received: by mail-ve0-f197.google.com with SMTP id d10sf7674090vea.4 for ; Wed, 19 Jun 2013 10:06:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=e4uizR8PYdgJP8ZnSo77fVrb/DAyYzQxHNBTz+JRYJg=; b=XnyGMzroWxkHiJ84oU8I4yCrpzAvUT54SjxGFeKj2aD8NEqqLr8yqH7uXR7xf3VcJh UbEydOuIrmdD/dC6ezCV0Eem01VAzxt0VPgoDXoB/vg0v+cvFODKQaJN4z4YBqPiQEPO B+9FvzL6l/f1DWBVAk4NOWZp8CgqOcVROmDVsX1Q9qF08bngM7yOvCIVMBD1suowYwtE afRTMf3nzVS+8ol4X8VYjqX+sERb/NsS7KRaTtMDLdENzIERVUwToMoqPO21tWP9IO+U FKTeShfvuBZgd8RJF6I+1Z2zG4KiK1ED2TJpMByxcVeSk9mBcK5e12xjRtNFGEJLw4kU Z8+Q== X-Received: by 10.236.80.106 with SMTP id j70mr2074571yhe.11.1371661600965; Wed, 19 Jun 2013 10:06:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.116.197 with SMTP id jy5ls371077qeb.10.gmail; Wed, 19 Jun 2013 10:06:40 -0700 (PDT) X-Received: by 10.49.94.174 with SMTP id dd14mr83671qeb.14.1371661600173; Wed, 19 Jun 2013 10:06:40 -0700 (PDT) In-Reply-To: X-Original-Sender: cxx@kayari.org 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:5111 Archived-At: ------=_Part_3695_1868215.1371661599764 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, June 19, 2013 5:57:47 PM UTC+1, Zhihao Yuan wrote: > > On Wed, Jun 19, 2013 at 12:25 PM, Nicol Bolas > > wrote: > > And you've just made a convincing argument not to do this. > > "it's more like" does not mean "they are the same". The two problems are > completely different, but the rationale which makes intuitive things work > is > similar. > > > Furthermore, `const` members of a class are not implicitly static data > > members, yet `const` globals implicitly have internal linkage, like > `static` > > globals. Why should `constexpr` behave differently in this regard? > > Just because it's intuitive. An object is of states, the states can > contain > read-only parts, but not non-states, i.e., constants. A constant defined > in a class scope is just some name can be looked up by the member > functions, you don't need a static keyword here to understand it. > But constexpr member functions aren't implicitly static member functions. Does it enable new features not currently available? No it would just save some typing. Does your proposal make the language more regular? I would argue no, because a constexpr member variable would be implicitly static, but a constexpr member function would not. const at namespace scope implies static linkage, constexpr at namespace scope implies static linkage. const on a member variable does not imply anything about linkage, and does not make the member static. Your proposal to change the meaning of constexpr on a member variable does not imply anything about linkage, but makes the member static. That's inconsistent with *everything* else. Does it make the langue easier to teach? No, due to the same inconsistency between member variables and member functions. What are you hoping to achieve except saving a bit of typing? -- --- 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_3695_1868215.1371661599764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 5:57:47 PM UTC+1, Zhihao Yuan wrote:On Wed, Jun 19, 2013 at 12:25 PM,= Nicol Bolas <jmck...@gmail.com> wrote:
> And you've just made a convincing argument not to do this.

"it's more like" does not mean "they are the same".  The two probl= ems are
completely different, but the rationale which makes intuitive things wo= rk is
similar.

> Furthermore, `const` members of a class are not implicitly static = data
> members, yet `const` globals implicitly have internal linkage, lik= e `static`
> globals. Why should `constexpr` behave differently in this regard?

Just because it's intuitive.  An object is of states, the states c= an contain
read-only parts, but not non-states, i.e., constants.  A constant = defined
in a class scope is just some name can be looked up by the member
functions, you don't need a static keyword here to understand it.
 
But constexpr member functions aren'= t implicitly static member functions.

Does it enable new features no= t currently available?  No it would just save some typing.

Does= your proposal make the language more regular?  I would argue no, beca= use a constexpr member variable would be implicitly static, but a constexpr= member function would not.  const at namespace scope implies static l= inkage, constexpr at namespace scope implies static linkage. const on a mem= ber variable does not imply anything about linkage, and does not make the m= ember static. Your proposal to change the meaning of constexpr on a member = variable does not imply anything about linkage, but makes the member static= .. That's inconsistent with *everything* else.

Does it make the langu= e easier to teach?  No, due to the same inconsistency between member v= ariables and member functions.

What are you hoping to achieve except= saving a bit of typing?


 

--
 
---
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_3695_1868215.1371661599764-- .