Generic Property Implementation

[Alex]

On Monday, 12 March 2018 at 07:04:19 UTC, Simen Kjærås wrote:
> On Saturday, 10 March 2018 at 17:43:06 UTC, Simen Kjærås wrote:
>> I'm not sure how fixable this is, but I am sure that there's 
>> plenty of benefit to being able to write code like this:
>>
>> struct S {
>>     int n, m;
>>     SomeType!(() => n + m) a;
>> }
>>
>> over this:
>>
>> struct S {
>>     int n, m;
>>     auto a() { return SomeType!(() => n + m)(); }
>> }
>>
>> Anyways, I filed a bug for it:
>> https://issues.dlang.org/show_bug.cgi?id=18587
>
> Actually, this is not fixable. If we consider for a moment the 
> internals of SomeType in the above code, it's something like 
> this:
>
> struct SomeType(alias fn) {
>     S* context;
> }
>
> The full layout of S then becomes this:
>
> struct S {
>     int n;
>     int m;
>     S* a.context; // points to 'this'.
> }
>
> Since structs in D are defined to be movable by blitting only, 
> with no cleanup afterwards, internal pointers are a no-no. Ref 
> https://dlang.org/spec/garbage.html:
>
>> Do not have pointers in a struct instance that point back to 
>> the same instance. The trouble with this is if the instance 
>> gets moved in memory, the pointer will point back to where it 
>> came from, with likely disastrous results.
>
> One possible solution would be for the above code to generate 
> the function a() instead of making 'a' a member. This has its 
> own set of issues, though - suddenly something that looks like 
> a member isn't one, and its address can't be taken, it can't be 
> passed by ref, etc.
>
> --
>   Simen

This is strange...

An incomplete type is perfectly ok, so there should be no problem 
with a pointer of the same type inside a struct.
If accidentally the pointer refers "this", then it must have been 
set after construction. As before construction the value of 
"this"-pointer does not exist and after the construction the 
pointer to "this" has the default value of null.

Therefore, you are aware of this circumstance and appropriate 
movings of the pointer value are also up to you.

On the other side:

Isn't it the case, that

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.

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.