Use moved core.lifetime.move{,Emplace} for std.algorithm.mutation.move{,Emplace}

[wilzbach]

In dlang/druntime#2442, doesPointTo wasn't ported as it's quite big (dlang/druntime#2447).

That's why one test which test this behavior would fail now. Should we simply move doesPointTo to druntime as proposed, s.t. we don't need to maintain two implementations?

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#6848"

[edi33416]

Why not delete instead of commenting?

[wilzbach]

I wanted to see whether this is the only issue.
As explained, the core.lifetime functions are technically different and using them is a breaking change.

[LightBender]

@thewilsonator this one is for you.

[0xEAB]

This one is painful because core.lifetime didn’t do its homework and breaks compatibility with existing code.
See: https://github.com/dlang/dmd/blob/35f1146a1b537e9a361fa28098a1cfc9a384178f/druntime/src/core/lifetime.d#L2192

Which is particularly painful to fix/emulate downstream because of the if (false) { nonTrustedImpl(); } trustedImpl(); @safety hacks used in the code that are inaccessibly from the outside (private “impl” functions).

[0xEAB]

The code forces @system at users of the public API, yet internally relies on having the chance of having @safe inferred.

[0xEAB]

std/typecons.d(3988): Error: cannot read uninitialized variable `payload` in CTFE
            () @trusted { moveEmplace(value, _value.payload); }();

Also looks like the druntime implementation now lacks a bit of CTFE-ability that the Phobos one has.
I suppose that one’s on me, actually.

[0xEAB]

I figure, emulating the previous behavior might be a hopeless endeavor.

Everything is built around moveEmplaceImpl (the incompatible function in question), so in order to sneak in a wrapper around that, pretty much everything else this PR tries to remove has to stay in with moveEmplaceImpl calls directed to the emulator.

AFAICT a more reasonable way forward would be to fix core.lifetime by restoring the missing behavior of emplaceMove() from Phobos. Though, I’m afraid that would be a good chunk of work.