220 5961 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Thu, 29 Aug 2013 02:06:34 +0200 Lines: 129 Approved: news@gmane.org Message-ID: References: <5e23a0e9-2bd9-4f62-aa83-47bea8144eae@isocpp.org> <521DAAF4.3050100@beamways.com> <521DE3EC.4040404@beamways.com> <521E8AB0.6070906@numericable.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e014946400e8ccd04e50ae155 X-Trace: ger.gmane.org 1377734794 12711 80.91.229.3 (29 Aug 2013 00:06:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2013 00:06:34 +0000 (UTC) Cc: Ville Voutilainen To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBBC5B7KIAKGQEYZZYYYY@isocpp.org Thu Aug 29 02:06:37 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEpky-0003O2-Rh for gclcip-std-proposals@m.gmane.org; Thu, 29 Aug 2013 02:06:37 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id wc20sf26009976obb.5 for ; Wed, 28 Aug 2013 17:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc: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=R40xEM6MWEFYUyx2v5/b3CJ2hFFUTAPUIhuCpcFlAm8=; b=jckdR1vEyu5Rrp0ZmfM0juH1KItX3d6Lm21awhL594gamzz+hfmt5enbGbVfwfuZB+ 3mT7m4jQr0jC/Fkt/wBHie4G9r6iPG0hryBrLBLPIke4fIe1chxsjj1cLOBpT7wyFtg4 un1q+v1+mHs1GT6U1lCV+RZe145DWapHfeb2J4+Zl18inBHImUmqj4YkSEGxz/DdvVzI UByzKluQ6GLa3FoCGoA5/PiIFnlENeHjSFEz5r2oyWb69kUuEyg/I+RougwEiO0INxW/ +Ci84qHaA4PpPxIJESvRDr7uDR0ZHhWWjtbNUcic0eXG4erUhu+0UgSmuMluzCaV5mcp UseQ== X-Received: by 10.182.61.75 with SMTP id n11mr132838obr.13.1377734795763; Wed, 28 Aug 2013 17:06:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.87.229 with SMTP id bb5ls107596obb.13.gmail; Wed, 28 Aug 2013 17:06:35 -0700 (PDT) X-Received: by 10.60.62.101 with SMTP id x5mr359240oer.24.1377734795325; Wed, 28 Aug 2013 17:06:35 -0700 (PDT) Original-Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [2607:f8b0:4003:c02::234]) by mx.google.com with ESMTPS id nk8si356519obb.76.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 17:06:35 -0700 (PDT) Received-SPF: pass (google.com: domain of mjklaim@gmail.com designates 2607:f8b0:4003:c02::234 as permitted sender) client-ip=2607:f8b0:4003:c02::234; Original-Received: by mail-oa0-f52.google.com with SMTP id f4so8740010oah.11 for ; Wed, 28 Aug 2013 17:06:35 -0700 (PDT) X-Received: by 10.60.16.104 with SMTP id f8mr7822oed.71.1377734795101; Wed, 28 Aug 2013 17:06:35 -0700 (PDT) Original-Received: by 10.76.27.194 with HTTP; Wed, 28 Aug 2013 17:06:34 -0700 (PDT) In-Reply-To: X-Original-Sender: mjklaim@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mjklaim@gmail.com designates 2607:f8b0:4003:c02::234 as permitted sender) smtp.mail=mjklaim@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) d=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:5961 Archived-At: --089e014946400e8ccd04e50ae155 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 29, 2013 at 1:49 AM, Nick wrote: > could you clarify what you mean by non-auto property? > I believe Loic means that if I have a initial version of some code that look like this: struct K { int count; }; int f( K& k ) { return k.count; } Then (years) later I upgrade it with some checks using some property syntax, but want to keep the retrocompatibility: class K // another retrocompatible change { public: property int count { //* */ } } Assuming the property works like a public variable, then this is useful. However, if I started my code like this, as a lot of code does: struct K { int count(); }; int f( K& k ) { return k.count(); } Then there is no benefit in upgrading to properties, because it will not be retro-compatible. I don't have an opinion on this point. However it might point that a property feature without a way to implicitely use member functions like if they were properties (as some suggested) would not use useful for code that is already written. It feels a bit like allowing k.count() to be written count(k) : it might help generalization, but only with new code. Joel Lamotte -- --- 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/. --089e014946400e8ccd04e50ae155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, Aug 29, 2013 at 1:49 AM, Nick <nicolas.jinchereau@gmail= ..com> wrote:
could you clarify what you mean by non-au= to property?

I believe Loic means that if I have a in= itial version of some code that look like this:

struct K
{
<= div class=3D"gmail_extra">=A0 =A0 int count;
};

int f( K&am= p; k )
{
= =A0 =A0return k.count; =A0
}

Then (y= ears) later I upgrade it with some checks using some property syntax, but w= ant to keep the retrocompatibility:

class K // another retrocompatible change
{
public:
=A0 =A0=A0
=A0 =A0 property int count { //* */ }

}

Assuming the property works like a public vari= able, then this is useful.

However,= if I started my code like this, as a lot of code does:

struct K
{
=A0 =A0 int count();
};

int f( K& k )
{
=A0 =A0return k.count(); =A0
}

Then there is no benefit in upgrading to prope= rties, because it will not be retro-compatible.

I don't have an = opinion on this point. However it might point that a property feature witho= ut
a way to implicitely use member functions like if they were properties (as = some suggested) would not use useful for code
that is already written.
It feels a bit like allowing k.count() to be written count(k) : it mi= ght help generalization, but only with new code.


Joel Lamotte

--
 
---
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>.
--089e014946400e8ccd04e50ae155-- .