Make move CTFEable for simple structs and classes

[DmitryOlshansky]

memcpy is not CTFEable, so avoid it for structs without
dtor, postblit that also can be assigned with plain lhs = rhs;.

This leaves as is (compile error in CTFE) structs that contain
immutable/const memebers the fact that moves overwrites such
fields is questionable to begin with.

Remark: pointsTo doesn't work at CTFE. The check itself makes no sense for class instances and primitive types.

[monarchdodra]

You also need to test hasElaborateAssign.

Once you test hasElaborateAssign, I don't think there's any need to test for hasElaborateCopyConstructor!T or hasElaborateDestructor!T either. Just:

static if (hasElaborateAssign!T || !isAssignable!T)

In that order. Unless I missed something? It's what we do in the rest of phobos anyways.

[DmitryOlshansky]

It seems you are right except for hasElaborateDestructor, since we must do memcpy to avoid calling destructor on void-initialized result.

[monarchdodra]

You are over thinking it. If anything cause a = * to do anything other than a straight up bit copy, then a will have an elaborate assign, and be marked as such, and that will be the end of that.

struct S
{
    ~this(){}
}

void main() 
{
    static assert(hasElaborateAssign!S);
}

So I agree that "destructor" => "must do memcpy", but you are already covered by "destructor" => "elaborate assign".

[DmitryOlshansky]

@monarchdodra
As noted destructor must be checked separately.
As to isElaborateAssign vs ElaborateCopyConstructor - I'd rather keep things the same way they were originally.

[monarchdodra]

As noted destructor must be checked separately.

Yes, there are two separate operations, with two separate tests:

• knowing if you can call assign: !hasElaborateAssign!T && isAssignable!T
• dealing with destruction: hasElaborateCopyConstructor!T || hasElaborateDestructor!T

As to isElaborateAssign vs ElaborateCopyConstructor - I'd rather keep things the same way they were originally.

Dealing with destruction is indeed unchanged. The assignement test is new, so there's no "keeping things the same way they were originally".

---

In any case, hasElaborateAssign must indeed be checked for. Let's get it fixed and get this show on the road.

[DmitryOlshansky]

In any case, hasElaborateAssign must indeed be checked for. Let's get it fixed and get this show on the road.

Well, I honestly do not care which combination of traits to use. hasElaborateAssign docs may need update to indicate compiler's generated ones count. Anyway changed to hasElaborateAssign.

[monarchdodra]

LGTM, but needs a rebase now.

hasElaborateAssign docs may need update to indicate compiler's generated ones count.

You or me? I tend to be not so good at writing documentation.

[DmitryOlshansky]

LGTM, but needs a rebase now.

Done.

You or me? I tend to be not so good at writing documentation.

I'll take a shot at docs.

[monarchdodra]

Auto-merge toggled on

[DmitryOlshansky]

Thanks!