Skip to content

Remove excessive conformance of Value.init(:) parameter to Codable - #227

Open
samkudr wants to merge 1 commit into
modelcontextprotocol:mainfrom
samkudr:ValueInit
Open

samkudr wants to merge 1 commit into
modelcontextprotocol:mainfrom
samkudr:ValueInit

Conversation

@samkudr

@samkudr samkudr commented May 20, 2026

Copy link
Copy Markdown
Contributor

Value.init(:) requires its parameter to conform to Codable but actually it needs just Encodable value.

Motivation and Context

The current requirement is literally excessive: the initializer encodes the incoming value to Value, the same way JSONEncoder encodes the incoming value to Data.

How Has This Been Tested?

In my project I was forced to extend conformance of some types to Decodable also, while knowing that it is never used.

Breaking Changes

No.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

ianegordon added a commit to ianegordon/swift-sdk that referenced this pull request Sep 11, 2026
The change is correct — Value.init(_:) only ever encodes its argument, so
the Codable constraint is over-tight — but it fixes no bug, and unlike
every other entry in the manifest its absence upstream is a compile error
rather than a runtime fault. Fork code passing an Encodable-only type
would not build against upstream unless modelcontextprotocol#227 lands there, turning the
return this fork exists to make easy into a build break. No downstream
needs the looser constraint today.

Moved from the candidate table to 'Not included, and why'. Remaining
candidates renumbered 7-10 to 6-9 so the intended order still continues
the manifest sequence. modelcontextprotocol#278's note no longer calls itself the second
Value.swift edit in the batch, since modelcontextprotocol#227 was the first.

Tracking: fork issue #13, relabelled decline.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Eb9yGSXH1TVkg5Afsu9phk
ianegordon added a commit to ianegordon/swift-sdk that referenced this pull request Sep 11, 2026
The Windows build failure is real — Package.swift provides EventSource
only on Apple platforms while HTTPClientTransport.swift imports it behind
#if !os(Linux) — and widening the five guards to os(Linux) || os(Windows)
is the obvious fix. It is inert on macOS and Linux by inspection.

But that it actually fixes Windows cannot be verified here: no Windows
machine, and ci.yml runs macos-latest and ubuntu-latest only. Windows is
low priority for this fork's downstreams, so an unverifiable patch is not
worth the divergence.

Cheap to reverse if that changes: unlike modelcontextprotocol#227, this cannot make fork code
fail to build against upstream.

Moved from the candidate table to 'Not included, and why'. Remaining
candidates renumbered 7-9 to 6-8 so the intended order still continues
the manifest sequence.

Tracking: fork issue #9, relabelled decline.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Eb9yGSXH1TVkg5Afsu9phk
@varun06

varun06 commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

Hi @samkudr, thanks for this PR! I've reviewed it and it looks good to merge.

Could you please rebase it onto the latest main? CI was broken on macOS runners for every PR (a toolchain/SDK mismatch, fixed in #306), so rebasing will pick up the fix and give us a green run. I'll review and merge once it's updated.

If you're no longer able to work on this, no problem: just let us know. If we don't hear back in about two weeks, we may carry the change forward in a new PR, with credit to you.

@samkudr

samkudr commented Oct 22, 2026

Copy link
Copy Markdown
Contributor Author

@varun06 I used GitHub interface for rebasing, I hope it did it correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants