220 6003 <30814fed-fb64-4fa6-af93-37503132ef78@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Properties Syntax Date: Fri, 30 Aug 2013 02:35:49 -0700 (PDT) Lines: 483 Approved: news@gmane.org Message-ID: <30814fed-fb64-4fa6-af93-37503132ef78@isocpp.org> References: <5e23a0e9-2bd9-4f62-aa83-47bea8144eae@isocpp.org> <5458c2e0-2e03-444e-a34d-4960a07b94ad@isocpp.org> <1797e481-d39e-4ba0-b797-6c0a8db862aa@isocpp.org> <2c5357aa-611b-4e40-b21d-b01799779619@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_494_33053281.1377855350005" X-Trace: ger.gmane.org 1377855349 12336 80.91.229.3 (30 Aug 2013 09:35:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Aug 2013 09:35:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBB5WOQGIQKGQE44FLIUI@isocpp.org Fri Aug 30 11:35:53 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VFL7Q-000692-6g for gclcip-std-proposals@m.gmane.org; Fri, 30 Aug 2013 11:35:52 +0200 Original-Received: by mail-qc0-f199.google.com with SMTP id n7sf1853802qcx.2 for ; Fri, 30 Aug 2013 02:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=nA4bXu8WbUVUBUl/Qd+dAvSS1iYQ3qxgpVgPDURNLT8=; b=W/PpH4ka914isRpHM1pWzPKvIfKpdNaCnukzabHu5YXTZ6GFIyijtvB6QtJDPj4MfZ tMTXbjibCbdiw0AeX71ScMichqE9AqQvFtIoAAy70FUZabAG1ZKVHzBfGySSBkyGfi1i OUpiHGm+nEzRPqX4ZLPRgeSznq72dU47THkmFjEyh6f1tUnxztATVNj64Q/CsPDkztuc pk2gCmJ40GMlgnaRcmhpCY52ADvKEIhCC6j6G1k2haag74XDUWrvJpFPdXdL9YKTM7YO BNuHBfnxeykxCKIgZVW2N4HFUYRcKBBT4N6qJ4lrY7Hj+yZL0T75w2AuOLbzmh4SC8ok mqBQ== X-Received: by 10.236.193.6 with SMTP id j6mr2786330yhn.44.1377855351305; Fri, 30 Aug 2013 02:35:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.94.71 with SMTP id da7ls1172634qeb.49.gmail; Fri, 30 Aug 2013 02:35:50 -0700 (PDT) X-Received: by 10.49.133.201 with SMTP id pe9mr329586qeb.6.1377855350646; Fri, 30 Aug 2013 02:35:50 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:6003 Archived-At: ------=_Part_494_33053281.1377855350005 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, August 29, 2013 10:03:38 AM UTC-7, Ville Voutilainen wrote: > > On 29 August 2013 19:26, Nick >wrote: > >> and in terms of anything happening at compile time, that pretty much >> falls under the category of a library implementation, which IMO has been >> thoroughly discussed already, and ruled out as far as standardization >> goes. >> > > I have seen zero evidence of any "ruling out". What we have is vocal > opinions from people > who aren't trying to explore the library possibilities, or any other > possibilities for that matter, > very hard. > We aren't trying to "explore the library possibilities" because it's a waste of time. They fundamentally cannot work; not without significant cruft and limiting the utility of the functionality. I have no idea what "other possibilities" refers to. If you're talking about the reflection stuff, save it; that's not an actual feature of any standard, nor is it a proposed feature *for* any standard. It's the twinkle in some people's eyes; it doesn't count as a "possibility" since a non-existent proposal cannot be adequately evaluated. The essential essence of properties, as a construct, is the effective transformation of these expressions (given `Type variableName`): auto data = variableName.field; variableName.field = data2; Into these: auto data = variableName.SomeGetterFunction(); variableName.SomeSetterFunction(data2); This is what the feature is; if a properties implementation cannot do this, it is non-functional. C++14, as a language, *cannot do this*. Not *correctly*. Not in all cases. `variableName.field` is a variable name. It *must* be a variable name. Therefore, any C++11/14-based library solution, *no matter how it is implemented*, must ultimately put a member variable named `field` in `Type`. It won't be the type that `SomeGetterFunction` returns, but it must be *some type*. Here is a short list of the holes that this creates in the abstraction: * Since `field` is a non-static data member, it takes up space. Even if it's just one `char` in size, it has already broken the layout of your class. You therefore cannot use these properties on any class that has strict layout needs. Let alone strict *memory* needs. * Since `field` is a public non-static data member, it is not private. Therefore, your class cannot be standard layout if you want private variables too. Admittedly, this is not very important since you just broke whatever layout compatibility you might have had by putting a member variable there. But it's still there. * Since `field` is a variable, it has a type. A type that is notably separate from the return type of the hypothetical `SomeGetterFunction`. The simple `auto data = variableName.field` completely breaks the abstraction by deducing the field's actual type, rather than the hypothetical return type. There may be more, but this is enough. It doesn't matter *how* these are implemented; the mere fact that it's a *variable* is the problem. These failures of the abstraction *cannot be fixed*. Every library implementation will have these failures. Not being able to be used on standard layout types is a *complete deal-breaker* as far as users are concerned. One of the most obvious uses for properties is on simple vector and point classes: class vec3 { public: float GetX() {return _x;} float GetY() {return _y;} float GetZ() {return _z;} void SetX(float val) {_x = val;} void SetY(float val) {_y = val;} void SetZ(float val) {_z = val;} private: float _x, _y, _z; }; Properties need to be able to work on this class. It needs to be able to take those getters and setters and make it look like this to the user: vec3 vec(...); vec.x = 4; auto data = vec.z; Ignoring the question of whether such a class should even have accessors, *every library solution* will change the layout of this class. Every library solution will make the class no longer standard layout. And that's not acceptable, because it is very important to the utility of this class that it remain layout-compatible with various interfaces. If it's not layout-compatible with a simple struct of 3 floats, then it simply cannot do its job. That's a fundamental part of its interface. *That* is what makes this a hack, a kludge. The abstraction has many points of failure, and they're all very easy to hit. They confine the library "solution" to a far more limited range of utility. If the user of a feature, *especially* one that exists to make coding more convenient, has to be constantly thinking about niggling issues like this, or to avoid their use in common circumstances, then this is clearly not an acceptable method of implementation. This is much like Boost.Lambda, where you frequently have to do things like use `boost::ref` and such to create reference wrappers for things. And note that this analysis does not need to look at an implementation. Every pure-library implementation will have these faults. There are more that I could look at, but I hope I've made my point: there's nothing to be gained by looking at "solutions" that *a priori* cannot succeed in any meaningful way. If someone wants to propose properties, such alternatives need to be > explored > by a proposal paper, otherwise I see little reason to say anything but > "thanks for sharing" > about such a proposal. > Why? It's a simple question. Why? No other proposals had to go through that. I don't recall Bjarne Stroustrup having to explore Boost.ConceptCheck before talking about innumerable versions of concepts. I don't recall the people proposaing static_if having to explore various Macro methods and such before making their proposal. I don't recall the r-value reference guys having to try to implement Boost.Move before being able to get people to look seriously at in-language move support. Are you saying that the the reflection group should have to investigate all possible library solutions for compile-time reflection before talking about their wanted language features? Sure, they may have made reference to attempts to implement them. But none of them dwelled on them at any real length. Why? Because they knew a priori that there was no way to do the feature any justice without real, language-level support. And if they could do that, then why is *required* that properties proponents explore alternative "solutions" in order for them to get a reasonable hearing on the idea of a language feature? What is so special about properties as a construct that it needs to have someone explore all of the myriad of ways that it *cannot possibly work* as a library feature? If you don't like properties as a feature *just say so*. If you don't want properties as a langauge feature, *just say so*. You don't have to hide behind "make it work as a library, then we'll see". Just say, "it's pointless and I don't want to see it in C++;" it's that simple. I think the reason you want this "exploration" of library implementations is that you don't want properties. *Ever*. What you want is to find all of the places where the kludge-implementation of properties fails. Then, like adding spackling paste to a crumbling wall, you will add random features to C++ so that the kludge won't fail there. And you'll keep adding "standard spackle" until the kludge-implementation of properties gets to some "well enough" point, by a completely and wholely arbitrary metric. And then you'll use that as a justification for why we shouldn't have it as a real language feature. No other C++ feature was built this way. I didn't see uniform initialization doing that. They didn't have to go through Boost.Assign and build up a random list of features that would make Boost.Assign work more cleanly. They came up with a completely separate syntax. They said that they could do it better and more reasonably by ignoring the library kludge and *doing it right*. I didn't see lambdas proposal going through Boost.Lambda and Boost.Phoenix, picking and choosing places where they could maybe add a few low-impact language features that would improve various aspects of the implementation and some such. No, they ignored the library kludge and *did it right*. So why do you single *this* idea out? -- --- 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_494_33053281.1377855350005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, August 29, 2013 10:03:38 AM UTC-7, Ville Vout= ilainen wrote:
On 29 August 2013 19:26, Nick <nicolas.j...@gmail.com> wrote:
and in terms of = anything happening at compile time, that pretty much falls under the catego= ry of a library implementation, which IMO has been thoroughly discussed already, and ruled out as far as standardization goes.<= /font>

I have seen zero evidence of any "ru= ling out". What we have is vocal opinions from people
who aren't trying = to explore the library possibilities, or any other possibilities for that m= atter,
very hard.

We aren't trying to= "explore the library possibilities" because it's a waste of time. They fun= damentally cannot work; not without significant cruft and limiting the util= ity of the functionality. I have no idea what "other possibilities" refers = to. If you're talking about the reflection stuff, save it; that's not an ac= tual feature of any standard, nor is it a proposed feature for any s= tandard. It's the twinkle in some people's eyes; it doesn't count as a "pos= sibility" since a non-existent proposal cannot be adequately evaluated.
=
The essential essence of properties, as a construct, is the effective t= ransformation of these expressions (given `Type variableName`):

auto data =3D variableName.field;
variableName.field =3D data2;

Into these:

auto data =3D variableName.SomeGetterFunction();
variableName.SomeSetterFunction(data2);

This is what the feature is; if a prope= rties implementation cannot do this, it is non-functional.

C++14, as= a language, cannot do this. Not correctly. Not in all cases.=

`variableName.field` is a variable name. It must be a variab= le name. Therefore, any C++11/14-based library solution, no matter how i= t is implemented, must ultimately put a member variable named `field` i= n `Type`. It won't be the type that `SomeGetterFunction` returns, but it mu= st be some type.

Here is a short list of the holes that this = creates in the abstraction:

* Since `field` is a non-static data mem= ber, it takes up space. Even if it's just one `char` in size, it has alread= y broken the layout of your class. You therefore cannot use these propertie= s on any class that has strict layout needs. Let alone strict memory= needs.
* Since `field` is a public non-static data member, it is not pr= ivate. Therefore, your class cannot be standard layout if you want private = variables too. Admittedly, this is not very important since you just broke = whatever layout compatibility you might have had by putting a member variab= le there. But it's still there.
* Since `field` is a variable, it has a = type. A type that is notably separate from the return type of the hypotheti= cal `SomeGetterFunction`. The simple `auto data =3D variableName.field` com= pletely breaks the abstraction by deducing the field's actual type, rather = than the hypothetical return type.

There may be more, but this is en= ough. It doesn't matter how these are implemented; the mere fact tha= t it's a variable is the problem. These failures of the abstraction = cannot be fixed. Every library implementation will have these failur= es.

Not being able to be used on standard layout types is a compl= ete deal-breaker as far as users are concerned. One of the most obvious= uses for properties is on simple vector and point classes:

class vec3
{
public:
   float GetX() {= return _x;}
   float GetY() {return _y= ;}<= span style=3D"color: #000;" class=3D"styled-by-prettify">
   <= /span>float GetZ() {return _z;}<= br>
   void SetX<= /span>(float val) {_x =3D val;}<= /span>
  =  void= SetY(float val) {_y =3D<= /span> val= ;}
   <= span style=3D"color: #008;" class=3D"styled-by-prettify">void SetZ(float val) = {_z =3D val;}

private:
  float _x, _y,<= /span> _z<= span style=3D"color: #660;" class=3D"styled-by-prettify">;
};

Propert= ies need to be able to work on this class. It needs to be able to take thos= e getters and setters and make it look like this to the user:

<= span style=3D"color: #000;" class=3D"styled-by-prettify">vec3 vec(...);
vec.x =3D 4;auto data =3D vec.z;

Ignoring the questi= on of whether such a class should even have accessors, every library sol= ution will change the layout of this class. Every library solution will= make the class no longer standard layout.

And that's not acceptable= , because it is very important to the utility of this class that it remain = layout-compatible with various interfaces. If it's not layout-compatible wi= th a simple struct of 3 floats, then it simply cannot do its job. That's a = fundamental part of its interface.

That is what makes this a = hack, a kludge. The abstraction has many points of failure, and they're all= very easy to hit. They confine the library "solution" to a far more limite= d range of utility.

If the user of a feature, especially one = that exists to make coding more convenient, has to be constantly thinking a= bout niggling issues like this, or to avoid their use in common circumstanc= es, then this is clearly not an acceptable method of implementation. This i= s much like Boost.Lambda, where you frequently have to do things like use `= boost::ref` and such to create reference wrappers for things.

And no= te that this analysis does not need to look at an implementation. Every pur= e-library implementation will have these faults. There are more that I coul= d look at, but I hope I've made my point: there's nothing to be gained by l= ooking at "solutions" that a priori cannot succeed in any meaningful= way.

If s= omeone wants to propose properties, such alternatives need to be explored
by= a proposal paper, otherwise I see little reason to say anything but "thank= s for sharing"
about such a p= roposal.

Why?

It's a si= mple question. Why?

No other proposals had to go through that. I don= 't recall Bjarne Stroustrup having to explore Boost.ConceptCheck before tal= king about innumerable versions of concepts. I don't recall the people prop= osaing static_if having to explore various Macro methods and such before ma= king their proposal. I don't recall the r-value reference guys having to tr= y to implement Boost.Move before being able to get people to look seriously= at in-language move support. Are you saying that the the reflection group = should have to investigate all possible library solutions for compile-time = reflection before talking about their wanted language features?

Sure= , they may have made reference to attempts to implement them. But none of t= hem dwelled on them at any real length. Why? Because they knew a priori tha= t there was no way to do the feature any justice without real, language-lev= el support.

And if they could do that, then why is required t= hat properties proponents explore alternative "solutions" in order for them= to get a reasonable hearing on the idea of a language feature? What is so = special about properties as a construct that it needs to have someone explo= re all of the myriad of ways that it cannot possibly work as a libra= ry feature?

If you don't like properties as a feature just say so= . If you don't want properties as a langauge feature, just say so. You don't have to hide behind "make it work as a library, then we'll see= ". Just say, "it's pointless and I don't want to see it in C++;" it's that = simple.

I think the reason you want this "exploration" of library im= plementations is that you don't want properties. Ever. What you want is to find all o= f the places where the kludge-implementation of properties fails. Then, lik= e adding spackling paste to a crumbling wall, you will add random features = to C++ so that the kludge won't fail there. And you'll keep adding "standar= d spackle" until the kludge-implementation of properties gets to some "well= enough" point, by a completely and wholely arbitrary metric.

And th= en you'll use that as a justification for why we shouldn't have it as a rea= l language feature.

No other C++ feature was built this way. I didn'= t see uniform initialization doing that. They didn't have to go through Boo= st.Assign and build up a random list of features that would make Boost.Assi= gn work more cleanly. They came up with a completely separate syntax. They = said that they could do it better and more reasonably by ignoring the libra= ry kludge and doing it right.

I didn't see lambdas proposal g= oing through Boost.Lambda and Boost.Phoenix, picking and choosing places wh= ere they could maybe add a few low-impact language features that would impr= ove various aspects of the implementation and some such. No, they ignored t= he library kludge and did it right.

So why do you single t= his idea out?

--
 
---
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_494_33053281.1377855350005-- .