new feature to move methods and fields between types

[amanthatdoescares]

Add Move Member Refactoring Code Action (refactor.move)

This PR introduces a new Move Member Code Action to Swift LSP that allows users to move a member declaration (e.g. property, method, enum case) from one type to another.

The action is surfaced under the Refactor… menu when the cursor is placed inside a member of a nominal type (struct, class, or enum). It is not offered for top-level declarations.

The implementation adds a new provider in:

Sources/SwiftLanguageService/CodeActions/MoveMember.swift

which detects MemberBlockItemSyntax at the cursor position and returns a command-based Code Action (swift.moveMember) of kind "refactor.move".

Tests Added

Added test coverage in:

Tests/SourceKitLSPTests/CodeActionTests.swift

• testMoveMemberCodeAction
• testMoveMemberCodeActionNotOfferedForTopLevelCode

feature: #2384

[plemarquand]

What client implements the swift.moveMember command? How do you choose what type to move the method/field to?

[amanthatdoescares]

What client implements the swift.moveMember command? How do you choose what type to move the method/field to?

Thanks for raising this. At the moment, the PR only adds the server-side code action and command, and the client interaction needed to select the destination type is not implemented yet.

I’ll complete the expected LSP flow by adding support to query valid destination types, allowing the client to prompt the user, and then execute swift.moveMember with the selected target. I’ll put this up for review again once the full interaction is implemented end-to-end.

[plemarquand]

What does the list of destination types look like? Is it only ones in the same file? same module? entire project? How do you avoid overwhelming the user with potentially 100s of options? What is the UX in the client for picking a destination type?

[amanthatdoescares]

What does the list of destination types look like? Is it only ones in the same file? same module? entire project? How do you avoid overwhelming the user with potentially 100s of options? What is the UX in the client for picking a destination type?

That makes sense. I’ll take this into account while revisiting the design and will avoid a broad project-wide destination list.

Before finalizing the approach, I plan to start a discussion on the Swift forums outlining the proposed behavior (limiting destinations to structurally valid containers in the immediate lexical hierarchy) to gather feedback and ensure alignment on the intended UX and scope.

I’ll proceed with implementation once there’s clarity and consensus around the direction.