You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, PIG will issue an error and fail the build if any product types are present that:
have both optional and variadic elements.
have any optional elements are not grouped together at the end of the production definition.
These are actually relics left over from a time when we non-present optional values were simply omitted from s-expression representation. The rules were necessary to avoid ambiguity when converting from the s-expression representation to the Kotlin classes. However, since this validation logic was added we modified it so that we now represent non-present optional values with Ion nulls, and therefore this static check shouldn't be needed anymore.
Thus, the following product definitions which are not valid today, should actually be valid:
(product foo bar::(? int) bat::int)
(product foo bar:: int bat::(? int) baz::(* int 0))
Note that, product types still can only support a single variadic element and that it must be at the end and this cannot change unless we also change how we represent variadic elements and that is beyond the scope of this issue.
The text was updated successfully, but these errors were encountered:
Currently, PIG will issue an error and fail the build if any
product
types are present that:These are actually relics left over from a time when we non-present optional values were simply omitted from s-expression representation. The rules were necessary to avoid ambiguity when converting from the s-expression representation to the Kotlin classes. However, since this validation logic was added we modified it so that we now represent non-present optional values with Ion
null
s, and therefore this static check shouldn't be needed anymore.Thus, the following
product
definitions which are not valid today, should actually be valid:Note that,
product
types still can only support a single variadic element and that it must be at the end and this cannot change unless we also change how we represent variadic elements and that is beyond the scope of this issue.The text was updated successfully, but these errors were encountered: