zcash_client_backend: rename and restructure Recipient::InternalAccount / BuildRecipient#2596
Merged
Merged
Conversation
…ielded Rename `Recipient::InternalAccount` (and the `BuildRecipient`/`PcztRecipient` mirrors) to `InternalShielded`, for symmetry with `Recipient::InternalTransparent`. The prior name did not communicate the actual distinction between the two internal variants, which is payload domain (shielded note vs. transparent address) rather than any special relationship to "the account" — as noted in review of #2550: #2595 The enum-level and per-variant doc comments on `Recipient` are expanded to spell out the two independent axes the variants vary along (relationship to the wallet, and payload domain). `PcztRecipient`'s variant order (and thus its postcard encoding) is unchanged; only the variant name changes for that private mirror type. Co-Authored-By: Claude <noreply@anthropic.com>
Split the private BuildRecipient type into ShieldedBuildRecipient and
TransparentBuildRecipient, matching the two functions that previously
consumed a single BuildRecipient with two unreachable!() arms apiece
(into_recipient_with_note, used only for shielded outputs where a decrypted
Note is available; into_recipient_with_outpoint, used only for transparent
outputs where an OutPoint is available). Each split type now carries only
the variants relevant to its domain, and each has a single into_recipient
method that is a total function over its variants.
PcztRecipient::from_recipient is likewise split into
from_shielded_recipient and from_transparent_recipient.
When the transparent-inputs feature is disabled, TransparentBuildRecipient
has only its (always-present) External variant, which does not reference
AccountId; a never-constructed Unconstructible(PhantomData<AccountId>,
Infallible) variant keeps AccountId a used type parameter in that
configuration, while letting the exhaustiveness of matches on the type be
proven by the compiler (`match absurd {}`) rather than asserted at runtime.
This is a private, internal-only change with no effect on the public API.
Follow-up from #2595
Co-Authored-By: Claude <noreply@anthropic.com>
nuttycom
approved these changes
Jul 10, 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
2 participants
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.
Resolves #2595.
Two commits:
Renames
zcash_client_backend::wallet::Recipient::InternalAccount(and itsBuildRecipient/PcztRecipientmirrors) toInternalShielded, for symmetry withRecipient::InternalTransparent. The prior name did not communicate the actualdistinction between the two internal variants — payload domain (shielded note vs.
transparent address), not some special relationship to "the account". The
Recipientenum doc comments are expanded to spell out the two independent axes thevariants vary along. This is a public, semver-breaking rename; a
Changedentry isadded to the unreleased section of
zcash_client_backend/CHANGELOG.md.PcztRecipient's variant order (and thus its postcard encoding within a PCZT) isunchanged.
Splits the private
BuildRecipienttype intoShieldedBuildRecipientandTransparentBuildRecipient, matching the two functions that previously consumed asingle
BuildRecipientwith twounreachable!()arms apiece(
into_recipient_with_note, used only for shielded outputs where a decryptedNoteis available;
into_recipient_with_outpoint, used only for transparent outputswhere an
OutPointis available). Each split type carries only the variantsrelevant to its domain, and each has a single
into_recipientmethod that is atotal function.
PcztRecipient::from_recipientis likewise split. This is aprivate, internal-only change with no effect on the public API.
Both follow from review discussion on #2550:
#2550 (comment)
Verification
cargo fmt --all -- --checkcargo clippy --all-features --all-targets -- -D warnings(workspace)cargo check -p zcash_client_backendwith--all-features,--no-default-features,--features transparent-inputs,--features orchardcargo test --workspace --all-features(all green, no failures)cargo doc --no-deps --workspace --all-features --document-private-items(nightly):no new warnings (4 pre-existing warnings, unrelated to this change)
Co-Authored-By: Claude noreply@anthropic.com