Generic Property Implementation

[Simen Kjærås]

On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote:
> * binary assignment operators (e.g. +=)
> * unary assignment operators (e.g. ++)
> * @safe, @nogc, and -betterC compatible
> * at least as good code generation as that proposed in the DIP 
> when optimizations are enabled.
> * And should be scalable to data that isn't addressable (e.g. 
> bitfields).  See
> https://issues.dlang.org/show_bug.cgi?id=16187

This is the best I've come up with in the current language:

struct S {
     int n;
     mixin property!("field", "get => this.n", "set => this.n = 
set");
}

unittest {
     import std.conv : to;
     S s;
     s.field = 3;
     assert(s.field == 3);
     s.field += 2;
     assert(s.field == 5);
     s.field++;
     assert(s.field == 6);
     assert(s.field.to!string == "6");
}

Sadly, there are issues:

1) Wrong return type:
unittest {
     S s;
     auto a = s.field;
     // Fails - typeof(a) is Property!((get) => this.n, (set) => 
this.n = set)
     assert(is(typeof(a) == int));
}
Not a whole lot to do about this. I've pondered writing a DIP on 
auto-decaying/rvalue types, which would decay to a different type 
the moment they're passed to a function or assigned to a 
variable. The feature would probably not be worth the trouble, 
though.


2) Noisy syntax:
If I had my druthers, mixin templates would be mixin'd 
automatically, and eponymous mixin templates would be a thing. 
That would give us this syntax:

struct S {
     int n;
     property!("get => this.n", "set => this.n = set") field;
}


3) Stringy functions:
The string literal functions are an eyesore, but would require 
some compiler work to fix. This fails:

struct S {
     int n;
     mixin property!("field", get => this.n, set => this.n = set);
}

The reason is there's no 'this' at the point of instantiation, 
since we're in the context of the type, not a function where 
'this' makes sense. It seems to me this should be fixable, but I 
have no idea how much work would be required.


4) 'this' in function bodies
It should be possible to write "get => this.n" as "get => n". 
There's no ambiguity as to which 'n' I'm referring to. Filed a 
bug:
https://issues.dlang.org/show_bug.cgi?id=18584

Implementation:
https://gist.github.com/Biotronic/5849af011cbe9c7ea05515011d5995bf

--
   Simen