220 33731 <6ed2bd55-5538-418f-8f1a-263a9958babd@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Evan Teran Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: properties? Date: Wed, 9 Aug 2017 10:32:28 -0700 (PDT) Lines: 328 Approved: news@gmane.org Message-ID: <6ed2bd55-5538-418f-8f1a-263a9958babd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5635_1439829336.1502299948753" X-Trace: blaine.gmane.org 1502299957 10500 195.159.176.226 (9 Aug 2017 17:32:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Aug 2017 17:32:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCDNZQVEQMLRBLMOVXGAKGQE67SD4NQ@isocpp.org Wed Aug 09 19:32:32 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfUqG-00024G-IS for gclcip-std-proposals@m.gmane.org; Wed, 09 Aug 2017 19:32:24 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id 110sf25019027uac.3 for ; Wed, 09 Aug 2017 10:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=d8WUa3jbPm1lmtUZt1C0yDYVQ3xohn/Ytq31y66ITmo=; b=sQ5+kr26NdULnRm2tpxHB1uNPPB/EWXu3Hf41t0ik/Hw2DxLiBV6+2vvATXfcDObQG mK+gvc4NcjeXaRoTqLW9Oql+K2mZHeyDYm8jjbU6ooTrdmfuAAWxC6NscCCNlRmIhKwn zzbUOKOn5806/+Jf/Ceu5y6tuBgkoGTjRqQyeZNgZrmyD/eRs0i6mt05chzXpFdd0Xox UHzhh3H1l6qfEcaIXMlLcNTIBbm/6/cOjGamphnrBJf6CsgMcQyx2YHKU1Pb5V9TU/zB O3ps7/w+F6TG06AgEspx8YEyY3QkG1Ec8dao1YFXi4Tlq3IqhjU5AUaAbRtGIR6YDar2 dUkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=d8WUa3jbPm1lmtUZt1C0yDYVQ3xohn/Ytq31y66ITmo=; b=UdNEzNuLAgri0oE8w7/y7DDztnD3NunCK4FX7lGK4iFfuesOWeURln2QO8yW9J5JSt B6MAR8jv9Dqw57iZqmk5pw4yuRjxmCVTxDcyKJRe5nubr6gtiaphgHnf5ECzi99fkEqJ 0hrElurJC6WGkbbPQORu5qeW/i68R3S4pyX8a1C6IXtPskLQcwNzwezGtRVJfXDqUUF/ pdg63nBj5+7AvxSStgS4pIL1aABji+6EGgqomkAOVZA3N04XAp9H1f4fv3TAQmi+B6QM 0DdVpupsWVCCZJheVVJ0CffdZyaSBtBG5VstDlDZcj0v0D9D1iX1amEtwru7T0RufWcS dkeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=d8WUa3jbPm1lmtUZt1C0yDYVQ3xohn/Ytq31y66ITmo=; b=j/zFxg5HnGzVKnziUhv3brXq/DofVzAMGvlvdvMtzwoHbx8cLATaTFNJOXmpdSnqFf lGLdAXM+S6vDlMMbXB9ibOIdMV64YOg7a93s5JssdiVuy9CI6SaeWY0orObIv5kCRwpg 2+nVVmWu++Rp0kZkK0ZBB5++PafCelV6dSnVDPYau/qHOynMa/e4buTcQiPKba0Bl0jh A+vLEa+344Del68agGk/8jPlirIFdtH5xWfCDSno7Y6NOhGxjBIEcSB+EHqi2wFbozym AdUvQS9QK2s3u2B8Bw2v+S5lo7k9vWbyU3WOs1+TYHjgT/JcIxQQUaE2TdZpTHN6VloF KKWA== X-Gm-Message-State: AHYfb5jorf+ekcHEj3NWBrOw7PNwJ2hB2+sb52zkHiRUxNKI57PwmRxO C9Wr9I56iCPHV6o/ X-Received: by 10.159.57.223 with SMTP id p31mr5274794uag.48.1502299950607; Wed, 09 Aug 2017 10:32:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.103.205 with SMTP id u196ls6141368itc.22.gmail; Wed, 09 Aug 2017 10:32:29 -0700 (PDT) X-Received: by 10.31.41.67 with SMTP id p64mr35369vkp.16.1502299949153; Wed, 09 Aug 2017 10:32:29 -0700 (PDT) X-Original-Sender: evan.teran@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:33731 Archived-At: ------=_Part_5635_1439829336.1502299948753 Content-Type: multipart/alternative; boundary="----=_Part_5636_195812855.1502299948754" ------=_Part_5636_195812855.1502299948754 Content-Type: text/plain; charset="UTF-8" I never brought it up before because I assumed that it MUST have been discussed in the past... but a search turns up nothing. Is there any thoughts about introducing properties to classes/structs/unions? Like lambdas, I kinda envision them as syntactic sugar for public member variables which overload cast operators and operator=. I can imagine something like this (forgive adhoc syntax I'm making up on the spot..., I think that the specific syntax is less important than whether or not the feature is desirable) class T { public: [[property]] int data = [ read_data, write_data ]; public: int read_data() const { return data_; } void write_data(int n) { data_ = n; } private: int data_; }; Not pretty, but I suspect that we can come up with something better. The idea is that this would be roughly equivalent to the following code: class T { public: struct data_impl { T& operator=(int n) { self->write_data(n); return *self; } operator int() const { return self->read_data(); } T *self; } data = { this }; public: int read_data() const { return data_; } void write_data(int n) { data_ = n; } private: int data_; }; The idea being of course that this makes code such as the following valid: T value; value.data = 10; std::cout << value.data << "\n" I can imagine a few benefits for properties: 1. If we encourage the use of properties over named getters and setters, then it makes long term maintenance of code simpler with better API stability. We can write code initially just using public member syntax if there is no need for special handling on reading or writing of the member. If the need ever arises to have special handling during read or write, then it the code only needs to change in the class itself. The code which uses it need not change at all (obvious exceptions involving taking the address of a member, but taking the address of a property could just be a hard error since it doesn't make much sense in the typical case). 2. Can replace a lot of uses of bifields which often result in undefined or platform specific behaviors. A user could create properties which represent each bit and can do the masking themselves to ensure in a reliable way that the bits they intend to work with are the ones which actually get used regardless of endian issues. Like I said, I'm less interesting in the bikeshedding of syntax concerns, but more interested in the relative merits and concerns with this type of feature. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6ed2bd55-5538-418f-8f1a-263a9958babd%40isocpp.org. ------=_Part_5636_195812855.1502299948754 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I never brought it up before because I assumed that it MUS= T have been discussed in the past... but a search turns up nothing. Is ther= e any thoughts about introducing properties to classes/structs/unions? Like= lambdas, I kinda envision them as syntactic sugar for public member variab= les which overload cast operators and operator=3D. I can imagine something = like this (forgive adhoc syntax I'm making up on the spot..., I think t= hat the specific syntax is less important than whether or not the feature i= s desirable)


class T= {<= span style=3D"color: #000;" class=3D"styled-by-prettify">
public:
=C2=A0 =C2=A0 [[property]] int data =3D [ read_data, write_data ];
public:
=C2=A0 =C2=A0 int read_data() const { return data_; }
=C2=A0 =C2=A0 void write_data(int n) { data_ =3D n; }<= br>private= :
=C2=A0 =C2=A0 <= /span>int<= span style=3D"color: #000;" class=3D"styled-by-prettify"> data_;
};

=
Not pretty, but I suspect that we can come up with something better. Th= e idea is that this would be roughly equivalent to the following code:
<= br>

<= div class=3D"subprettyprint">
class T {
public:
=C2=A0 =C2=A0 struct data_impl {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 T&<= span style=3D"color: #000;" class=3D"styled-by-prettify"> operator=3D(int n) {<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self->write_data(n);=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return *self;=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operator int() con= st = {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 return se= lf->read_data();
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 }
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 T *self;
=C2= =A0 =C2=A0 } data =3D { this };
public:
=C2=A0 = =C2=A0 int= read_data= ()<= span style=3D"color: #000;" class=3D"styled-by-prettify"> const { return data_; = }
=C2=A0 =C2=A0 <= /span>void= write_data(int n) { data_ =3D n= ; }
private:
=C2=A0 =C2=A0 int data_;
};

The idea being of course that this m= akes code such as the following valid:

=C2=A0 =C2=A0 T value= ;
=C2=A0 =C2=A0 value.data =3D 10;
=C2=A0 =C2=A0 std::cout << value.da= ta <<= ; <= span style=3D"color: #080;" class=3D"styled-by-prettify">"\n"

I can imagine a few benefits for = properties:

  1. If we encourage the use of properties over named= getters and setters, then it makes long term maintenance of code simpler w= ith better API stability. We can write code initially just using public mem= ber syntax if there is no need for special handling on reading or writing o= f the member. If the need ever arises to have special handling during read = or write, then it the code only needs to change in the class itself. The co= de which uses it need not change at all (obvious exceptions involving takin= g the address of a member, but taking the address of a property could just = be a hard error since it doesn't make much sense in the typical case).<= /li>
  2. Can replace a lot of uses of bifields which often result in undefin= ed or platform specific behaviors. A user could create properties which rep= resent each bit and can do the masking themselves to ensure in a reliable w= ay that the bits they intend to work with are the ones which actually get u= sed regardless of endian issues.
Like I said, I'm less in= teresting in the bikeshedding of syntax concerns, but more interested in th= e relative merits and concerns with this type of feature.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/6ed2bd55-5538-418f-8f1a-263a9958babd= %40isocpp.org.
------=_Part_5636_195812855.1502299948754-- ------=_Part_5635_1439829336.1502299948753-- .