Ensure Move Constructor Requires Copy Constructor (#20942)

[khushishukla2813]

This PR addresses the issue where a move constructor is silently ignored if no copy constructor is declared. According to the D specification, when a move constructor is declared, a copy constructor should also be present. However, this requirement was not enforced in the compiler, leading to unexpected behavior.

Changes & Fixes:
Added an explicit error message:

If a move constructor is declared without a corresponding copy constructor, the compiler now generates an error:
error(this.loc, "Move constructor declared without a corresponding copy constructor.");
This prevents silent failures and ensures the specification is followed.
Updated hasCopyConstruction function:

Previously, hasCopyConstruction() only checked for postblit || hasCopyCtor.
Now, it also considers hasMoveCtor, ensuring that the presence of a move constructor triggers the necessary checks.
Removed the commented-out condition that was preventing proper enforcement:

The check hasMoveCtorLocal && !hasCpCtorLocal was previously commented out to avoid build failures in vibe.d.
Instead of silently ignoring the move constructor, this PR explicitly enforces the requirement while preserving compatibility.
How This Fixes the Issue:
Ensures that a move constructor is not ignored without a copy constructor, aligning with the D language specification.
Provides a clear error message to guide developers in properly defining their struct constructors.
Improves compiler correctness and prevents unintended behavior when move semantics are used.
This PR ensures consistency in constructor handling and prevents silent issues in struct initialization.

[dlang-bot]

Thanks for your pull request and interest in making D better, @khushishukla2813! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

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 run digger -- build "master + dmd#21041"

[khushishukla2813]

I’ve added a check to ensure that a move constructor is only allowed if a copy constructor is also declared, as per the D language specification. I’ve verified the changes locally by creating test cases and updating the build makefile.... but I’m encountering CI failures.
Can u have a look on my changes and point out where i am going wrong!
thanks!

[TurkeyMan]

This is said to be a breaking change, and that's why it wasn't in the first round.
There is code in the wild which declares a move ctor but no copy ctor. It's probably broken code, where someone thought they were implementing a copy ctor but got the signature wrong and didn't realise, but it exists all the same...
Walter decided it was necessary to be conservative and allow that code to keep working the way it does.

My suggestion was to deprecate that case in the future, but move ctors should get some exercise before that change.

[rikkimax]

CI failing due to: https://github.com/dlang/phobos/blob/96ab2077c3c0fc19181883ecb59af38082c47add/std/typecons.d#L11024

[khushishukla2813]

This is said to be a breaking change, and that's why it wasn't in the first round. There is code in the wild which declares a move ctor but no copy ctor. It's probably broken code, where someone thought they were implementing a copy ctor but got the signature wrong and didn't realise, but it exists all the same... Walter decided it was necessary to be conservative and allow that code to keep working the way it does.

My suggestion was to deprecate that case in the future, but move ctors should get some exercise before that change.

@TurkeyMan Umm got it! but... maybe we could start with a warning instead of an immediate error.. That way existing code still runs but devs get a heads-up to fix things before it becomes a hard rule..

[khushishukla2813]

I’ve added a check to ensure that a move constructor is only allowed if a copy constructor is also declared, as per the D language specification. I’ve verified the changes locally by creating test cases and updating the build makefile.... but I’m encountering CI failures.
Can u have a look on my changes and point out where i am going wrong!
thanks!

@rikkimax Thanks for pointing that out! I checked it but ran into a mess, so I ended up doing manual testing instead. What do you think would be the best approach here adjusting the check in my PR or updating the existing code to align with the spec!

[TurkeyMan]

100% agree with you! I suggested a depreciation warning for the rogue move constructors. (I reckon they're probably actually just wild bugs)
Sadly, I'm not the one that needs to be convinced.

That said, I do see some sense in getting move semantics somewhat working and proven before nagging people to adapt their code.

[rikkimax]

I’ve added a check to ensure that a move constructor is only allowed if a copy constructor is also declared, as per the D language specification. I’ve verified the changes locally by creating test cases and updating the build makefile.... but I’m encountering CI failures.
Can u have a look on my changes and point out where i am going wrong!
thanks!

@rikkimax Thanks for pointing that out! I checked it but ran into a mess, so I ended up doing manual testing instead. What do you think would be the best approach here adjusting the check in my PR or updating the existing code to align with the spec!

I agree with Manu about doing a deprecation.

You will also need to fix phobos so it passes, in a separate PR.

Until then we won't know how bad the situation is in the ecosystem since the buildkite tests are currently not running due to Phobos.