I see a valid point to get optional block since way pointed by Ben
causes creation of multiple wrappers.
Assuming that we have nested optional fields:
[type OptionalBlock
[implicit uint 32 'length' 'COUNT(data)' ]
[array int 8 'data' count 'length' ]
]
[type DataBlock [uint 16 'size']
[optional OptionalBlock 'size > 0' ]
]
After changes it would be:
[type DataBlock [uint 16 'size']
[optional 'size > 0'
[implicit uint 32 'length' 'COUNT(data)' ]
[array int 8 'data' count 'length' ]
]
]
I think that getting with optional flag under the hood will serve us
near term. However long term solution should introduce optional as a
block into our parser and generators. This will allow us to nest
multiple optional sections. Otherwise we will shift problem just one
level down.
Since this is not a strong requirement for 0.9 we might plan this after
we ship nearest release.
Best,
Łukasz
On 25.08.2021 13:05, Christofer Dutz wrote:
> Hi,
>
> as the discussion just came up on Slack ... taking it where it belongs ... on
> the list ;.)
>
> So the problem was, that it's difficult to have anything optional that is not
> a "simple" field.
>
> My Idea would be to change the way "optional" is used and to convert it into
> a wrapper element. It would just contain an expression and contain normal
> fields inside.
>
> So an
>
> [optional uint 8 "hurz" "some expression"]
>
> Would bebome:
>
> [optional "some expression"
> [simple uint 8 "hurz"]
> ]
>
> This way we could even wrap multiple elements inside the optional condition
> and all of our types.
> In general it would simply map to an if expression.
>
> I doubt the changes would be very significant. We would need to add an
> "optional" flag to the internal field types and set that to false in the
> general case but to true inside an optional field.
>
> Chris
>
