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

Remove excessive conformance of Value.init(:) parameter to Codable#227
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
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.

1 participant