Add SCSpecTypeUDTV2 with a type id - #310
Closed
leighmcculloch wants to merge 2 commits into
Closed
Conversation
This was referenced Jul 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Warning
Root of a stack of PRs that thread this field through the Rust libraries and the SDK. A valid merge order:
Refvariants of the generated typesReftypesSCSpecTypeUDTV2What
Add
SCSpecTypeUDTV2, a second form of user-defined type reference that identifies the type it references solely by an 8-byte opaqueid, and aSC_SPEC_TYPE_UDT_V2arm onSCSpecTypeDefholding it. Theidis opaque here; how it is derived is left to the spec producer, and the Rust SDK derives it from the referenced type's own definition.A reference carries no name. The name of a user-defined type lives on the definition entry the id identifies, so a consumer that wants the name resolves the id against the definitions in the same spec.
Why
A
SCSpecTypeUDTreference carries only a name, so a name is the only thing tying a reference to the definition it refers to. That is too weak to check anything against: names collide across libraries, and a definition whose shape changes while its name stays the same is indistinguishable from one that did not, so a consumer cannot tell whether theUdtStructa function accepts is theUdtStructit holds a definition for. Carrying an id that identifies the referenced type by content makes the link verifiable, and makes it well-defined for types that reference each other or themselves.Carrying the id instead of the name, rather than alongside it, keeps one thing identifying the referenced type instead of two that can disagree — there is no way to express a reference whose name says one type and whose id says another. Adding a variant rather than a field on
SCSpecTypeUDTkeeps every existing spec readable unchanged.