Behdad Esfahbod
Behdad Esfahbod
> > Also we would have to define a stack limit. > > Is there really a substantial difference between the depth of a postfix operator expression and the depth...
> I’m probably missing something, then: how is `ConditionAnd` different from `ConditionSet`? `ConditionAnd` has a format number at the beginning to differentiate it from other types. `ConditionSet` has no version/format...
> I guess the mention of deprecation threw me off, then. It will be obviated by the `ConditionAnd`. > So this is proposing additional formats for use within a `ConditionSet`...
Another issue with using magical offset values is that old code will misparse the data.
> I suppose the argument here is going to boil down to "This is like COLR v1 so it's better from a simplicity standpoint". That will probably win the day,...
If we were to go the stack-machine route, I suggest using: ``` struct { uint8 format; uint24 offset; } ``` instead of magic offset numbers.
Also, it can become prefix, to allow short-circuiting as Simon suggested. And the 24bits for the AND/OR formats can be used to encode number of operands.
> Also, it can become prefix, to allow short-circuiting as Simon suggested. Not quite. One still has to parse and skip over short-circuited items, unless we're at the top-level.
Based on the original desire (negating an entire ConditionSet) I suggest we stick to my design, which allows negation with 5 bytes. In Skef's proposal it would be 4 bytes...
Thanks Skef. What's procedurally the next step? @davelab6 @liamquin