Hi! I'm Govind(loveucifer), i wanted to discuss an idea for my proposal for gsoc 2026
i think when we are refactoring Swift code, we frequently need to inline a function — replacing a call site with the function's body. This is the inverse of "Extract to Function" and is one of the most useful refactoring operations in my opinon , Currently, doing this manually requires:
Navigate to the function definition
Copy the entire function body
Map each parameter to its corresponding argument at the call site
Substitute parameters with arguments throughout the copied body
Handle return values — assign them or replace return with the expression
Paste the modified body at the call site
Optionally delete the original function if it has no other callers
For even simple functions this takes 2-5 minutes and is error-prone. TypeScript and Rust developers do this with a single keyboard shortcut:
rust-analyzer has inline_call (~5000 LOC in extract_function.rs) and inline_into_callers
TypeScript LSP has inline refactoring built into VS Code
Current State in SourceKit-LSP
SourceKit-LSP has no inline function/call capability. The only "inline" action that exists is source.refactoring.kind.inline.macro (macro expansion), which is an entirely different feature — it expands Swift macros, not function bodies. I verified this by searching the entire codebase:
No inline_call, inline_local_variable, or inline_into_callers functionality
The .refactorInline LSP kind is used only as a category label for unrelated syntactic rewrites (integer literal conversion, De Morgan's law, etc.)
if i get some suggestions or pointers on this id be sure to put up a more well drafted proposal here , i just wanted to convey the idea before i pursue this any further
Hi! Interesting proposal — inline refactoring is definitely a powerful feature.
One thing I’m curious about: how do you plan to handle cases involving generic functions or functions capturing local context? For example, inlining a function that references self, mutates state, or relies on async/throws semantics might require careful handling of scoping and lifetime rules.
Also, would this be implemented purely at the syntax layer, or would it require semantic analysis support from SourceKit’s index?
Curious to hear how you’re thinking about these aspects.
Hi there,
Thank you for the idea! This could be a neat project indeed, I know I'd personally benefit from it even
I'm the org admin for Swift, I'm trying to find a mentor for this but it may be tricky with sourcekit-lsp specific projects this year as capacity to mentor on that is rather low...
hey @ktoso i dont mind implementing this even without gsoc tbh , i use swift a lot for my own passion projects and i often found the need for this , is there any way i can still do this ? ( also u tagged the wrong guy ) i know this is a huge project or atleast i think it is , is this a valid idea on the roadmap ?
From what I’ve heard and think myself this is a great idea, and for sure useful. Just that we’re unsure if we can find a mentor. I’ll keep you posted though if we do find someone
Hi @loveucifer, we searched around but noone on this side of the project is able to mentor this year. I would recommend you look into one of the pitched project ideas with mentors already assigned if you want to participate in GSoC.
If you'd like to work on this feature anyway that would be awesome of course, but we can't support it as part of GSoC this time, sorry to say.
