DIP23 draft: Fixing properties redux

[Tove]

On Wednesday, 6 February 2013 at 01:40:37 UTC, Andrej Mitrovic 
wrote:
> On 2/6/13, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> That's why some of us have suggested
>> making it so that you can mark variables with @property.
>
> What Jonathan means is this:
>
> struct S
> {
>     int var;  // modifiable, can take address
> }
>
> Now suppose later you want to turn var into a property:
>
> struct S
> {
>     @property int var();
>     @property void var(int);
> }
>
> This potentially breaks code if the user-code was using a 
> pointer to
> the public var field in the previous version of your library.
>
> So instead we should have the ability to annotate fields with 
> @property:
>
> struct S
> {
>     @property int var;  // modifiable, can *not* take address
> }
>
> There's no run-time cost, but it disallows taking the address 
> of var,
> and it allows you to introduce property functions in the future
> without breaking user-code.

It is also possible to first start with setters/getters and then 
switch to a public field(!)

Which leads to the conclusion, in order for the property 
abstraction to be complete, address taking of *anything* 
annotated with @property should either NOT be allowed...

@property int var();     // can *not* take address
@property void var(int); // can *not* take address
@property int var;       // can *not* take address

... or we have to guarantee that the type remains unchanged... 
which is problematic due to different types of the getter and 
setter, which would force one to always specify the expected type 
rather than relying on auto.

@property int var;
int  delegate()    d_get = &var;
void delegate(int) d_set = &var;