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
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
makes no
> sense that moving as a concept can fail at CTFE. That's what I
> find suspicious. [Maybe 'suspicious' isn't the right term; I
> couldn't express it better.] You can move rvalues at CTFE which
> proves that the compiler can do it.
>
> >> Shouldn't it be possible
hat moving as a concept can fail at CTFE. That's what I
find suspicious. [Maybe 'suspicious' isn't the right term; I
couldn't express it better.] You can move rvalues at CTFE which
proves that the compiler can do it.
Shouldn't it be possible to move at CTFE,
too, or does it mean, non-copyable types are p
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
() 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. Shouldn't it be possible to move at CTFE,
too, or does it mean, non-copyable types are practically unusable
for CTFE?
