220 5962 <1f562671-aa29-418d-b89f-d81092cb2be9@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nick Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Wed, 28 Aug 2013 17:18:11 -0700 (PDT) Lines: 263 Approved: news@gmane.org Message-ID: <1f562671-aa29-418d-b89f-d81092cb2be9@isocpp.org> 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="----=_Part_870_21621027.1377735491507" X-Trace: ger.gmane.org 1377735491 19697 80.91.229.3 (29 Aug 2013 00:18:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2013 00:18:11 +0000 (UTC) Cc: Ville Voutilainen To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC42HSUOVYGBBRFG7KIAKGQE5Z556TA@isocpp.org Thu Aug 29 02:18:14 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEpwD-0003sS-JL for gclcip-std-proposals@m.gmane.org; Thu, 29 Aug 2013 02:18:13 +0200 Original-Received: by mail-gh0-f199.google.com with SMTP id g14sf7210487ghb.2 for ; Wed, 28 Aug 2013 17:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=d63Z9Qs6g/8arPrhMo8KtfLRwmJn5magp5ptH8vbprU=; b=ChLCiLNx7Q1M65IIaX7XPvRlSfvOB5Uj7ZgjSFsGQolimbByVkM9y879keSb0Y1AIZ A9O6AWJ7SmIM0EiEB9wu0yc+iDeaJrPZy2aw5uXCfLdZFzJW+AgGJyCq0WY1MyHq1hl2 GF4RyChhcAnxTTTlBRrk+ck6b0dtL3RGd4OHjWI8MKZEp/zvWzj7A5dfLK6kikSnVxzV JbnVr5Zrc3Sg0htQb/AgRIb7GqmTcF0sOQ9KKMAN+oATOZ3ZxjCjfdNATcNWHrb3Zl0g A38fT7su+IToOSthp47wu7NqXobVWBdacyi5bFioCGf/ZoEY/nZG4JgE1JqhXIt8Wy2T TjPg== X-Received: by 10.236.63.165 with SMTP id a25mr151139yhd.43.1377735492693; Wed, 28 Aug 2013 17:18:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.94.71 with SMTP id da7ls577669qeb.49.gmail; Wed, 28 Aug 2013 17:18:12 -0700 (PDT) X-Received: by 10.49.128.129 with SMTP id no1mr16404qeb.23.1377735492258; Wed, 28 Aug 2013 17:18:12 -0700 (PDT) In-Reply-To: X-Original-Sender: nicolas.jinchereau@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:5962 Archived-At: ------=_Part_870_21621027.1377735491507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, 28 August 2013 20:06:34 UTC-4, Klaim - Jo=EBl Lamotte wrote: > > 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= =20 > look like this: > > struct K > { > int count; > }; > > int f( K& k ) > { > return k.count; =20 > } > > Then (years) later I upgrade it with some checks using some property=20 > syntax, but want to keep the retrocompatibility: > > class K // another retrocompatible change > { > public: > =20 > 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(); =20 > } > > Then there is no benefit in upgrading to properties, because it will not= =20 > be retro-compatible. > > I don't have an opinion on this point. However it might point that a=20 > property feature without > a way to implicitely use member functions like if they were properties (a= s=20 > 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= =20 > help generalization, but only with new code. > > > Joel Lamotte > > If I understand correctly, while std::vector is currently implemented like this: vector { size_t size() const { return _last - _first; } }; and the size can be taken like this: vector myVec; size_t sz =3D myVec.size(); then you are saying that the implementation of vector should be able to be= =20 upgraded to: vector { auto_property size_t size() const { return _last - _first; } }; and still allow for both usages? vector myVec; size_t sz1 =3D myVec.size(); size_t sz2 =3D myVec.size; If this is correct, then I agree completely, and I think that this is=20 feasible using the function based property syntax that I initially proposed= .. =20 --=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/. ------=_Part_870_21621027.1377735491507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wednesday, 28 August 2= 013 20:06:34 UTC-4, Klaim - Jo=EBl Lamotte wrote:

On Thu, Aug 29, 2013 at 1:49 AM, Nick <<= a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"bfOXUe0d9= -sJ">nicolas.j...@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>    int count;
};

int f( K& k )
{
   re= turn k.count;  
}

Then (years) later I upgrade it wit= h some checks using some property syntax, but want to keep the retrocompati= bility:

class K // another retrocompatible change
{
public:
<= div>    
    property int count { //* */= }

}

Assuming the property works like a pu= blic 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 t= here 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 mi= ght help generalization, but only with new code.


Joel Lamotte


<= div>
If I understand correctly,

while std::vect= or is currently implemented like this:

vector<T> {
    size_t size() const { return _last - = _first; }
};

=
and the size can be taken like this:

vector<int> myVec;
size_t sz =3D myVec.size<= span style=3D"color: #660;" class=3D"styled-by-prettify">();

then you are saying that the implementation = of vector should be able to be upgraded to:

vector<T> {
    auto= _property size_t size() const<= /span> { return _last - _first; }
};
and still allow for both usages?

vector<int> myVec;
size_t sz1 =3D myVec.size<= span style=3D"color: #660;" class=3D"styled-by-prettify">();
size_t sz2 =3D myVec.size;

If this is correct, then I agree completely, = and I think that this is feasible using the function based property syntax that I initially = proposed.
 

--
 
---
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_870_21621027.1377735491507-- .