[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976258#comment-13976258
]
Jens Geyer commented on THRIFT-2429:
------------------------------------
{quote}
Required fields with the default value will not be serialized
{quote}
This would break compatibility unnecessarily. Omitting an required field from
the wire would be an even bigger roadblock to upgrading services than any
changed default could be ever. Given two counterparts with different IDL
versions, you can break compatibility big time just by adding a default value
to a required field. Then the old server will complain and throw a "missing
required field" exception, because the default is no longer written by the
client. We consider bumping the version for {{float}}, but plan to change
well-documented {{required}} semantics silently? In don't think that's a good
idea.
Thinking about it, this makes Aleksey's proposal look quite concludent:
* {{required}} and {{normal}} defaults are write-side defaults
* {{optional}} defaults are read-side defaults
Sounds not so bad to me. The new operator/keyword doesn't either. I'm fine with
both.
> Provide option to not write default values, rely on receiver default
> construction instead
> -----------------------------------------------------------------------------------------
>
> Key: THRIFT-2429
> URL: https://issues.apache.org/jira/browse/THRIFT-2429
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
> Affects Versions: 0.9.1
> Reporter: Chris Stylianou
> Assignee: Randy Abernethy
> Labels: default, optional, required
>
> Would there be any objections to a patch that does not write default values
> (essentially the same logic as the optional attributes). This obviously
> relies on the receiving application using the same IDL version to ensure the
> defaults used on object construction match the senders.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
