Generic Property Implementation

[Simen Kjærås]

On Monday, 12 March 2018 at 10:37:00 UTC, Alex wrote:
> Sure, you have.
> https://dlang.org/spec/struct.html#assign-overload
> Point #4.
> In this case,
>
> ref S opAssign(ref S rhs)
> {
>     return this;
> }

True. Can you fix these, too?

struct S {
     S* ptr;
     this(int dummy) {
         ptr = &this;
     }
     ~this() {
         assert(ptr == &this);
     }
}

void test(S s) {}

unittest {
     test(S(0));
}

S test2() {
     return S(0);
}

unittest {
     S s = test2();
}


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

And why not? D allows for moving garbage collectors.



>> 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.

Yes, it's an example of code that works in D today, with similar 
semantics to those implied in the other example. It's meant to 
show that just like `auto tmp = typeof(S.a())()` doesn't work 
today, it shouldn't work with the types used in my other example.



>> 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);
> }

I think we may be speaking past one another. Yes, your unittest 
would be expected to pass.

If we go back to the example code:

struct S1 {
     int n, m;
     SomeType!(() => n + m) a;
}

vs.

struct S2 {
     int n, m;
     auto a() { return SomeType!(() => n + m)(); }
}

I would expect typeof(S1.a) and typeof(S2.a()) to be equivalent. 
I don't see a good reason why I should be able to construct an 
instance of typeof(S1.a), since I can't construct a 
typeof(S2.a()).

I see your point that "The latter closures above the current 
values inside of [S2]". I'm saying I want the former to do the 
same. I understand that it currently doesn't, and I argue that 
having it do the same would be a much more useful behavior. Apart 
from the fact it's impossible, I don't see any good reason not to 
make it work. :p

--
   Simen