The EncodeTagged and DecodeTagged functions take a function pointer, for performing the actual encoding/decoding.
Currently the signature of those functions assume they're working with non-null types, because the 'null-ness' is handled by being tagged (present or not present).
There's an exception to this though: Slice1 proxies sent by an Ice client. Because these can be 'set' to 'null'.
This PR fixes the code-gen to handle this case.
Proxies (and ServiceAddress) are just custom types. So now, for tagged Slice1 custom types, the code-generator will use (Encode|Decode)NullableCustomType instead of (Encode|Decode)CustomType.
This will add a slight performance hit (which is fine, since this is incredibly niche), and requires removing a notnull type restriction from the Slice1 only overload for DecodeTagged. The other 2 overloads are fine as is, since they;re Slice2 only and VSize specific respectively (custom types are _always FSize).
The
EncodeTaggedandDecodeTaggedfunctions take a function pointer, for performing the actual encoding/decoding. Currently the signature of those functions assume they're working with non-null types, because the 'null-ness' is handled by being tagged (present or not present).There's an exception to this though: Slice1 proxies sent by an Ice client. Because these can be 'set' to 'null'. This PR fixes the code-gen to handle this case.
Proxies (and
ServiceAddress) are just custom types. So now, for tagged Slice1 custom types, the code-generator will use(Encode|Decode)NullableCustomTypeinstead of(Encode|Decode)CustomType.This will add a slight performance hit (which is fine, since this is incredibly niche), and requires removing a
notnulltype restriction from theSlice1only overload forDecodeTagged. The other 2 overloads are fine as is, since they;reSlice2only andVSizespecific respectively (custom types are _always FSize).