DIP23 Counter Proposal

[Jonathan M Davis]

On Thursday, February 07, 2013 10:02:41 Steven Schveighoffer wrote:
> On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan <chadjoan at gmail.com> wrote:
> > On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
> >> ...
> >> 
> >> The semantic rewrite stuff is something I don't feel strongly either
> >> way. It would be nice, but at the same time, it doesn't feel necessary
> >> to me. One can always simply avoid it by not using the operators on
> >> properties.
> > 
> > A core feature of properties is that variables can be migrated to them
> > (and back) without breaking any of the caller's code. Forbidding more
> > than half of D's operators on them will definitely break this attribute.
> 
> I find this explanation lacking. A field supports operations that are
> impossible to implement with properties, there will never be a
> non-code-breaking change from a field to a property. So it's a matter of
> "how much" breakage you want to allow. This is really a judgment call,
> there is no "right" answer. The closest you can get to a field is to ref
> an actual field. But in that case, I don't see the point of the property,
> since you give unfettered access to the field!
> 
> The whole point of having properties that I see is to implement things you
> CAN'T implement with a field, or are more cumbersome. Like read-only
> fields. Such a change would necessarily and on purpose break code.

It works as long as you can limit the variable in some way. But I believe that 
the main purpose in using public variables rather than actual property 
functions when all they would do is get or set the variable is to avoid lots 
of boilerplate code. It's incredibly common to get stuff like

struct S
{
 int i() @safe const pure nothrow
 { return _i; }

 int i(int value) @safe pure nothrow
 { return _i = value; }

 private int _i;
}

That's a lot of extra code whose only benefit is encapsulation. So, it would be 
great if you could just do

struct S
{
 int i;
}

And with the ability to replace the variable with a property function later if 
it ever needs to do more than just get or set makes it so that encapsulation 
isn't a problem - except for the fact that there are certain operations that 
you can do on a variable that you can't do on a property function (e.g. taking 
its address or passing it by ref). Simply making it so that doing

struct S
{
 @property int i;
}

lowered into something like the first example would allow you to avoid all of 
that boilerplate code and still have full encapsulation.

It's definitely true that you can never make a property function completely 
emulate a variable, but all of the boilerplate required for simple getters and 
setters is kind of ridiculous. I believe that avoiding that is the primary 
reason that people want to be able to swap between variables and property 
functions, and with a small addition to the language, we can obviate that 
boilerplate.

- Jonathan M Davis