Support arrays, structs, and identifiers in ternary operators#3222
Open
mohammadfawaz wants to merge 1 commit into
Open
Support arrays, structs, and identifiers in ternary operators#3222mohammadfawaz wants to merge 1 commit into
mohammadfawaz wants to merge 1 commit into
Conversation
be16d8f to
f333d2e
Compare
f333d2e to
f6e5a6b
Compare
f6e5a6b to
d794d30
Compare
Collaborator
Author
|
Support for this in Leo is here: ProvableHQ/leo#29349 Shows on average 7.8% drop in Aleo program sizes across the Leo test suite. |
d794d30 to
fa9c2c2
Compare
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.
Summary
Extends the
ternaryinstruction to accept array, struct, and identifier operands (in addition to the pre-existing literal set), gated behindConsensusVersion::V15.consoleandcircuit: newTernaryimpls forLiteralandPlaintext(array/struct aware, recursive on fields/elements); newTernaryimpl forIdentifierLiteral.synthesizer-program:ternaryoperation now handles non-literal operands; type-checking ensures both branches have matching array shape / struct layout.synthesizer: cost model updated; deployment validation viacheck_no_non_literal_ternaryrejects non-literal / non-pre-V15-supportedternarybefore V15.Consensus gating
Before V15, deployments containing
ternaryon arrays, structs, oridentifieroperands are aborted — infunction,finalize,closure, andconstructorbodies. At V15 and later, they are accepted and executable.String is intentionally not supported
The
stringliteral type is not a permittedternaryoperand at any version:check_no_non_literal_ternary's pre-V15 allow-list excludesstring(it was never in the original macro-based list).ensure_no_string_leavescheck inTernary::output_typesrecursively walks the branch plaintext type and rejects anystringleaf (including inside arrays or structs, local or external).Rationale: Aleo strings are variable-length byte arrays, but the byte-wise MUX that underlies circuit ternary requires both branches to have matching byte-lengths. During deployment, circuit synthesis samples strings with
Literal::sample(String, rng), which yields random lengths; supporting strings would require either a padded sampling strategy or a graceful length-check path, neither of which is a small change. If we ever want strings, it would be a follow-up with its own consensus gate.Tests
synthesizer/src/vm/tests/test_v15/ternary_plaintext.rscovers:ternaryinsidefinalize.stringand structs containing astringfield).Unit tests in
console/program/src/data/literal/ternary.rsandcircuit/program/src/data/literal/ternary.rsexerciseLiteral::ternarydispatch across all supported variants, includingIdentifier.