-
Notifications
You must be signed in to change notification settings - Fork 67
SWIFT-858: Duplicate pure Swift BSON breaking changes in driver #477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## master #477 +/- ##
==========================================
- Coverage 76.89% 76.75% -0.14%
==========================================
Files 125 125
Lines 13012 13545 +533
==========================================
+ Hits 10005 10396 +391
- Misses 3007 3149 +142
Continue to review full report at Codecov.
|
kmahar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good! few small things to fix.
9d0b2b2 to
835cb46
Compare
kmahar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one more thing; also I think we need a rebase to resolve merge conflicts, and it looks like the tests need an update in order to compile
| public var rawValue: UInt8 | ||
|
|
||
| public init(_ value: UInt8) { self.rawValue = value } | ||
| public init?(rawValue: UInt8) { self.rawValue = rawValue } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the back and forth but I think maybe we should omit RawRepresentable conformance because the public initializers here allows users to bypass the validation of their custom subtype value. This is not great because a user could start using eg 0x07 as a custom subtype and then we could add a conflicting subtype in a future server version. 0x07-0x7F are reserved for future non-custom subtypes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea I think it would make more sense to not conform, I'll revert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to reignite this conversation, but could we not just return nil if a user specified a reserved but unused value? From the docs of RawRepresentable, this seems like the ideal case to conform to it (i.e. modeling a C style enum).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that is a good point, didn't think of that lol. i'm fine with returning nil for reserved subtypes
3b0878b to
34f3df1
Compare
kmahar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok 1 more comment again :)
also sorry for introducing more merge conflicts.... again we totally should have merged this before i did all the prefixing 🙈
f09201d to
52653b0
Compare
kmahar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new stuff LGTM but there are some issues from rebasing
kmahar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM assuming travis and evergreen pass!
All changes listed in ticket:
https://jira.mongodb.org/browse/SWIFT-858
Additionally changed:
BSONTypeisUInt8instead of UInt32