Move and CTFE

[Jonathan M Davis]

On Wednesday, May 30, 2018 20:42:38 Q. Schroll via Digitalmars-d-learn 
wrote:
> It seems one cannot std.algorithm.mutation.move objects
> explicitly. Say I have a non-copyable type
>
>      struct NoCopy
>      {
>          int payload; // some payload
>      pure nothrow @nogc @safe @disable:
>          this(this); // make it non copyable
>      }
>
> that is being used in a compile-time function evaluation where
> values are being moved.
>
>      int f() pure nothrow @nogc @safe
>      {
>          import std.algorithm.mutation : move;
>          NoCopy nc = NoCopy(1), nc2 = NoCopy(3);
>          nc = move(nc2);
>          return 0;
>      }
>
>      static assert(f() == 0); // trigger CTFE
>
> It fails because move() cannot be executed at compile time. The
> reason
>      "memcpy cannot be interpreted at compile time, because it has
> no available source code"
> sounds very suspicious.

Why is it suspicious? memcpy is a C function, and you can't call C functions
during CTFE precisely because the compiler doesn't have their source code.
You can't call D functions either if the compiler doesn't have their source
(e.g. if you're using a .di file to hide the implementation).

> Shouldn't it be possible to move at CTFE,
> too, or does it mean, non-copyable types are practically unusable
> for CTFE?

You can't do much in the way of pointer or memory manipulation during CTFE
(e.g. no pointer arithmetic or reinterpret casts). So, I don't see how a
move could be done during CTFE. Even if the source for memcpy were available
during CTFE, I suspect that it wouldn't be allowed due to the lower level
stuff that it does.

Maybe the newCTFE stuff that Stefan is working on can do more in this area
(I don't know), but in general, anything that's at all low-level is
forbidden in CTFE.

- Jonathan M Davis