Generic Property Implementation

[Alex]

On Monday, 12 March 2018 at 09:54:20 UTC, Simen Kjærås wrote:
>
> But I don't have a hook to update the pointer when the struct 
> is moved. The GC may move my struct without informing me in any 
> way. In fact, even just a copy construction will break this:
>
> struct S {
>     S* ptr;
>     this(int dummy) {
>         ptr = &this;
>     }
>     ~this() {
>         // This assert will fail.
>         assert(ptr == &this);
>     }
> }
>
> unittest {
>     S s1 = S(0);
>     S s2 = S(0);
>
>     assert(&s1 == s1.ptr);
>     assert(&s2 == s2.ptr);
>
>     s1 = s2;
> }
>
> The reason is copy construction makes a copy[1] of the lhs, 
> then performs the copy construction[2]. If the copy 
> construction[2] succeeds, the copy[1] is destroyed. If not, the 
> copy[1] is blitted back over the original, to give the 
> impression that nothing ever happened.
>
> When the destructor is called on the copy[1], &this returns a 
> different address from what it did before, since it's a copy 
> and logically resides at a different address.
>

Sure, you have.
https://dlang.org/spec/struct.html#assign-overload
Point #4.
In this case,

ref S opAssign(ref S rhs)
{
     return this;
}

Another point is, that I hope, that pointers don't move anywhere, 
as in C, by definition.

>
>> struct SomeType(alias fn) {}
>>
>> is (or has to be) lowered to something like
>>
>> struct SomeType
>> {
>>   typeof(fn)* fn;
>> }
>>
>> Even if fn contains a frame pointer to S it is perfectly legal 
>> to have such a type. SomeType would contain a delegate then.
>
> Indeed. But stack frames aren't copied or moved the way structs 
> are.
>

Yes. This is how the structs are meant to be, I thought :)

>
>> However, I think, the syntax
>>
>>>> struct S {
>>>>     int n, m;
>>>>     SomeType!(() => n + m) a;
>>>> }
>>
>> is still invalid and
>>
>>>> struct S {
>>>>     int n, m;
>>>>     auto a() { return SomeType!(() => n + m)(); }
>>>> }
>>
>> has another semantics.
>>
>> The latter closures above the current values inside of S.
>> The former has to be constructible without the context, as it 
>> is perfectly legal to write
>>
>> struct Outer
>> {
>> 	struct Inner{}
>> }
>>
>> void main()
>> {
>>   auto i = Outer.Inner();
>> }
>>
>> but would be impossible with this syntax.
>
> I'm not using any inner structs in my examples. SomeType is 
> assumed to be a separate type that knows nothing about S. If 
> you're saying this should work:
>

Ah... I was unclear, I think...

> unittest {
>     auto tmp = typeof(S.a)();
> }

I thought, this shouldn't be possible (at least in my mind)

>
> It wouldn't, and such code is not possible in D today:
>
> struct S {
>     int n;
>     auto a() { return SomeType!(() => n)(); }
> }
>
> struct SomeType(alias fn) {
>     int get() { return fn(); }
> }
>
But this is clearly valid.

> unittest {
>    // cannot access frame pointer of foo.S.a.SomeType!(delegate 
> () => this.n).SomeType
>    auto tmp = typeof(S.a())();
> }
>
For sure, tmp cannot be defined without an instance of S. So the 
correct unittest in my eyes would be:
unittest {
    S s;
    auto res = s.a;
    assert(res.get == S.init.n);
}


> --
>   Simen