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
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:
>
On Wednesday, 30 May 2018 at 21:02:07 UTC, Jonathan M Davis wrote:
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
[...]
It fails because move() cannot be executed at
On Wednesday, May 30, 2018 22:42:13 Q. Schroll via Digitalmars-d-learn
wrote:
> On Wednesday, 30 May 2018 at 21:02:07 UTC, Jonathan M Davis wrote:
> > On Wednesday, May 30, 2018 20:42:38 Q. Schroll via
> >
> > Digitalmars-d-learn wrote:
> >> It seems one cannot std.algorithm.mutation.move objects
On Wednesday, 30 May 2018 at 23:07:26 UTC, Jonathan M Davis wrote:
newCTFE is taking a very different approach to CTFE, and in
theory, it will fix many of the problems that CTFE currently
has, but it's taking Stefan quite a while to get it to where it
needs to be to actually merge it.
To
On Thursday, 21 June 2018 at 20:15:42 UTC, Stefan Koch wrote:
To give some more context here:
CTFE is the most well tested feature in dmd.
So there is no room for sloppiness or functional differences!
As you previously mentioned the newCTFE engine works on a
completely different basis then the
