220 5132 <9a4c139d-b08f-4dab-b5a3-9ff9d3139061@isocpp.org> 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 14:26:16 -0700 (PDT) Lines: 157 Approved: news@gmane.org Message-ID: <9a4c139d-b08f-4dab-b5a3-9ff9d3139061@isocpp.org> References: <300a19dd-8a82-4788-9802-45170480b30a@isocpp.org> <63d90b03-5605-476d-b40b-7ebcee0d3354@isocpp.org> <0df105c5-7019-4674-83ac-1b071964210b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2660_28040039.1371677176331" X-Trace: ger.gmane.org 1371677182 4967 80.91.229.3 (19 Jun 2013 21:26:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2013 21:26:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMONUNYS4IRB6GDRCHAKGQE4BXKVDA@isocpp.org Wed Jun 19 23:26:23 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UpPtS-0002su-8V for gclcip-std-proposals@m.gmane.org; Wed, 19 Jun 2013 23:26:18 +0200 Original-Received: by mail-gh0-f197.google.com with SMTP id r20sf4743863ghr.4 for ; Wed, 19 Jun 2013 14:26:17 -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=YVpaZYqRhrv/FUztD0DAfmCqXiEfUzI1Z7Xve/5TUoU=; b=F00u4fVrgQ3MbV/3kuaW5ZSWoom4BXmKkwLGf/7gjq2nXzGR5fkmZJkWdhmJFXHUpZ 4+GoDCxOFoun9AA+cjW4bRxH0vQ5PLw9242QN0WSPcU8xKJwUFoCQ2Bb8oE+nFv9Yy2+ Z6MKsWerI58oIbplbhV3TV7WX1ejxAVF4o1Y0dG9Oxnykbb22mDZRMZAHjkKF8v06ieA +jrbewJhHthsoBj66F+JkCf1CayHY4108BudtnZJ7Zfj72hiGYjWLMtP/X4g6JQcTBmD 0NoSzVcbrH6NyO/5YpVUPtIxZbrrWBGbHjJiRMlfvry34eEytPvn0OTLPRO//2KLJq3w bARA== X-Received: by 10.224.129.196 with SMTP id p4mr5001243qas.6.1371677177318; Wed, 19 Jun 2013 14:26:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.4.138 with SMTP id k10ls463493qek.15.gmail; Wed, 19 Jun 2013 14:26:16 -0700 (PDT) X-Received: by 10.49.15.74 with SMTP id v10mr109542qec.16.1371677176634; Wed, 19 Jun 2013 14:26:16 -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:5132 Archived-At: ------=_Part_2660_28040039.1371677176331 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, June 19, 2013 9:48:50 PM UTC+1, Zhihao Yuan wrote: > > On Wed, Jun 19, 2013 at 3:19 PM, Jonathan Wakely > > wrote: > >> But a variable defined in namespace scope default to have external > >> linkage, then why a `const` qualifier can change its linkage? > > > > So that simple named constants in separate translation units don't > interfere > > and you don't have to be careful about avoiding name clashes. > > So that simple named constants in class scope are not duplicated > for each object (not allowed, forever) and you don't have to care > about what the constants actually are. > That's an argument in favour of static data members existing, not an argument in favour of constexpr implying static. We already have them, they work fine, making constexpr imply static adds no new ability to the language and doesn't make it easier to express your designs. > > OK, but what about the consistency of constexpr data members and > consexpr > > member functions? > > Re-read your comment, consistency of a data member and a > member function -- for what? For whether they are static or not, obviously. struct A { static constexpr int one = 1; static constexpr int two() { return 2; } }; If I want A::one() and A::two() to be constexpr, I say so. If I want them to be static, I say so. You're proposing: struct A { constexpr int one = 1; static constexpr int two() { return 2; } }; If I glance at this code I do not immediately see that A::one is static. It looks like an instance variable. That's what I mean by consistency. Now consider: struct A { const int zero = 0; constexpr int one = 1; static constexpr int two() { return 2; } constexpr int three() { return 3; } }; Are you really suggesting that it makes the language easier to teach that A::zero is non-static and A::one is static? How does your mental model of "constexpr means it's just a constant, you don't need to care about storage.linkage etc." help here? Why does it imply static on A::one but not A::three? It's inconsistent. -- --- 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_2660_28040039.1371677176331 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 9:48:50 PM UTC+1, Zhihao Yuan wrote:On Wed, Jun 19, 2013 at 3:19 PM, = Jonathan Wakely <c...@kayari.org> wrote:
>> But a variable defined in namespace scope default to have exte= rnal
>> linkage, then why a `const` qualifier can change its linkage?
>
> So that simple named constants in separate translation units don't= interfere
> and you don't have to be careful about avoiding name clashes.

So that simple named constants in class scope are not duplicated
for each object (not allowed, forever) and you don't have to care
about what the constants actually are.

That's an argument in favour of static= data members existing, not an argument in favour of constexpr implying sta= tic.

We already have them, they work fine, making = constexpr imply static adds no new ability to the language and doesn't make= it easier to express your designs.
 
> OK, but what about the consistency of cons= texpr data members and consexpr
> member functions?

Re-read your comment, consistency of a data member and a
member function -- for what?

For whethe= r they are static or not, obviously.

struct A {
  static constexpr int one =3D 1;
  static cons= texpr int two() { return 2; }
};

If I wa= nt A::one() and A::two() to be constexpr, I say so. If I want them to be st= atic, I say so.

You're proposing:

struct A {
  constexpr int one =3D 1;
  static constexpr int two() { return 2; }
};
<= div>
If I glance at this code I do not immediately see that A= ::one is static. It looks like an instance variable.

That's what I mean by consistency.

Now consider= :

struct A {
  const int = zero =3D 0;
  constexpr int one =3D 1;
  stat= ic constexpr int two()  { return 2; }
  constexpr int t= hree()  { return 3; }
};

Are you really suggesting that it makes the language easier to teach that= A::zero is non-static and A::one is static?

How d= oes your mental model of "constexpr means it's just a constant, you don't n= eed to care about storage.linkage etc." help here? Why does it imply static= on A::one but not A::three?  It's inconsistent.

<= 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-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_2660_28040039.1371677176331-- .