The compiler currently rejects the combination of an optional type (Cell?) with the as remaining serialization annotation, despite the documentation explicitly stating that optionals can use the same serialization annotations as their underlying types.
Minimal Reproducible Example:
struct TestRemainingOptional {
prefix: Int as uint8;
data: Cell? as remaining; // Compiler rejects this line
}
contract TestContract {
s: TestRemainingOptional;
init(){
self.s = TestRemainingOptional{prefix:0, data:null};
}
receive() {}
}
Compiler Output:
Error: The "as remaining" field cannot have optional type
Expected Behavior (per documentation):
This combination (Cell? as remaining) should compile successfully. The optional type prefix (1-bit indicator) should determine if the remaining slice is parsed into a Cell or remains empty.
Documentation Reference:
"Optionals can have serialization annotations provided after the as keyword and have all the same serialization options as their encapsulated primitive or struct types."
This indicates a clear inconsistency between documented capabilities and actual compiler behavior.
LLM Fuzzing discovery (see #2490)
The compiler currently rejects the combination of an optional type (
Cell?) with theas remainingserialization annotation, despite the documentation explicitly stating that optionals can use the same serialization annotations as their underlying types.Minimal Reproducible Example:
Compiler Output:
Expected Behavior (per documentation):
This combination (
Cell? as remaining) should compile successfully. The optional type prefix (1-bit indicator) should determine if the remaining slice is parsed into aCellor remains empty.Documentation Reference:
This indicates a clear inconsistency between documented capabilities and actual compiler behavior.
LLM Fuzzing discovery (see #2490)