@@ -92,6 +92,11 @@ import Streamly.Internal.Data.Unbox.TH (DataCon(..))
92-- * 'inlineSerializeAt' (Just Inline)
92-- * 'inlineSerializeAt' (Just Inline)
93-- * 'inlineDeserializeAt' (Just Inline)
93-- * 'inlineDeserializeAt' (Just Inline)
95+-- The following experimental options are also available:
97+-- * 'encodeConstrNames' False
98+-- * 'encodeRecordFields' False
95data SerializeConfig =
100data SerializeConfig =
96 SerializeConfig
101 SerializeConfig
97 { cfgInlineSize :: Maybe Inline
102 { cfgInlineSize :: Maybe Inline
@@ -127,25 +132,26 @@ inlineDeserializeAt v cfg = cfg {cfgInlineDeserialize = v}
127-- | __Experimental__
132-- | __Experimental__
129-- In sum types, use Latin-1 encoded original constructor names rather than
134-- In sum types, use Latin-1 encoded original constructor names rather than
130−-- binary values to identify constructors. This option is not useful on a
135+-- binary values to identify constructors. This option is not applicable to
131−-- product type.
136+-- product types.
133−-- This option enables the following backward compatible behavior:
138+-- This option enables the following behavior:
135-- * __Reordering__: Order of the fields can be changed without affecting
140-- * __Reordering__: Order of the fields can be changed without affecting
136-- serialization.
141-- serialization.
137-- * __Addition__: If a field is added in the new version, the old version of
142-- * __Addition__: If a field is added in the new version, the old version of
138-- the data type can still be deserialized by the new version. The new value
143-- the data type can still be deserialized by the new version. The new value
139-- would never occur in the old one.
144-- would never occur in the old one.
140−-- * __Deletion__: If a field is deleted in the new version and deserialization
145+-- * __Deletion__: If a field is deleted in the new version, deserialization
141-- of the old version will result in an error. TBD: We can possibly designate a
146-- of the old version will result in an error. TBD: We can possibly designate a
142−-- catch-all field to handle this case.
147+-- catch-all case to handle this scenario.
144-- Note that if you change a type, change the semantics of a type, or delete a
149-- Note that if you change a type, change the semantics of a type, or delete a
145-- field and add a new field with the same name, deserialization of old data
150-- field and add a new field with the same name, deserialization of old data
146-- may result in silent unexpected behavior.
151-- may result in silent unexpected behavior.
148-- This option has to be the same on both encoding and decoding side.
153-- This option has to be the same on both encoding and decoding side.
149-- The default is 'False'.
155-- The default is 'False'.
151encodeConstrNames :: Bool -> SerializeConfig -> SerializeConfig
157encodeConstrNames :: Bool -> SerializeConfig -> SerializeConfig
@@ -161,11 +167,11 @@ encodeConstrNames v cfg = cfg {cfgConstructorTagAsString = v}
161-- | __Experimental__
167-- | __Experimental__
163-- In explicit record types, use Latin-1 encoded record field names rather than
169-- In explicit record types, use Latin-1 encoded record field names rather than
164−-- binary values to identify the record fields. Note that this option cannot be
170+-- binary values to identify the record fields. Note that this option is not
165−-- used on a sum type. Also, it does not work on a product type which is not a
171+-- applicable to sum types. Also, it does not work on a product type which is
166−-- record, because there are no field names to begin with.
172+-- not a record, because there are no field names to begin with.
168−-- This option enables the following backward compatible behavior:
174+-- This option enables the following behavior:
170-- * __Reordering__: Order of the fields can be changed without affecting
176-- * __Reordering__: Order of the fields can be changed without affecting
171-- serialization.
177-- serialization.
@@ -173,10 +179,10 @@ encodeConstrNames v cfg = cfg {cfgConstructorTagAsString = v}
173-- version of the data type can still be deserialized by the new version, the
179-- version of the data type can still be deserialized by the new version, the
174-- field value in the older version is assumed to be 'Nothing'. If any other
180-- field value in the older version is assumed to be 'Nothing'. If any other
175-- type of field is added, deserialization of the older version results in an
181-- type of field is added, deserialization of the older version results in an
176−-- error but only when that field is accessed in the deserialized record.
182+-- error but only when that field is actually accessed in the deserialized
177-- * __Deletion__: If a field is deleted in the new version and it is
184-- * __Deletion__: If a field is deleted in the new version and it is
178-- encountered in a previously serialized version then the field is discarded.
185-- encountered in a previously serialized version then the field is discarded.
179−-- TBD: We can possibly designate a catch-all field to handle this case.
181-- This option has to be the same on both encoding and decoding side.
187-- This option has to be the same on both encoding and decoding side.