On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:
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");
}
Not bad. Not good, but not bad either.
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));
}
This looks like a related issue:
https://issues.dlang.org/show_bug.cgi?id=16657. That's is a
deal-breaker for me, but I think it could be fixed.
2) Noisy syntax:
If I had my druthers, mixin templates would be mixin'd
automatically, and eponymous mixin templates would be a thing.
Yes, this would be nice, but I don't think it's a deal-breaker.
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.
Yeah, that's quite unfortunate; writing code in strings stinks.
I actually prefer the DIP for this issue alone.
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
Thanks for filing the issue. I just might be able to fix it;
I'll try.
Implementation:
https://gist.github.com/Biotronic/5849af011cbe9c7ea05515011d5995bf
You've done some great work here. I spent about an hour on this
yesterday, and my implementation started to require more and more
mixing strings to get it to work.
If all of the issues you've identified were addressed, you'd end
up with something like this (formatted in a C# way).
struct S {
int n;
property!
(
get =>
{
n
},
set =>
{
n = set
}
) field;
}
That's actually pretty darn good. It makes me wonder if I should
work on fixing those issues or continue with the DIP.
If you don't have any objections I'd like to incorporate this
implementation and your analysis into the DIP.
Thank you again for doing this; you've saved me a awful lot of
time, and have done more than I probably could have.
Mike
