-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Updates to tgmath functions for CGFloat #15360
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
Updates to tgmath functions for CGFloat #15360
Conversation
These changes bring CGFloat in line with the other FloatingPoint types. Some of this stuff is now defined at the protocol level, so we can get rid of it at the concrete type level, with an obsoleted message. A couple other functions have been deprecated for all types, with protocol or tgmath replacements.
@swift-ci please test. |
@_transparent | ||
public func modf(_ x: CGFloat) -> (CGFloat, CGFloat) { | ||
let (ipart, fpart) = modf(x.native) | ||
return (CGFloat(ipart), CGFloat(fpart)) | ||
} | ||
|
||
@available(swift, deprecated: 4.2, renamed: "scalbn") |
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.
It's weird to have something deprecated then provide a rename to something obsoleted in the same version.
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.
scalbn
is obsoleted for concrete types; there's a new scalbn
that's generic on BinaryFloatingPoint
.
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.
Ah! Thanks for the explanation.
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.
Any reason we can't just remove them, then?
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.
Not that I know of; ben and max recommended obsoleted
. If you think removal is viable, I'll make another PR for that.
% if T == 'Double': | ||
// Functions that are defined only for Double | ||
% if T in ['Double','CGFloat']: | ||
// Functions that are defined only for Double and CGFloat |
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.
This does run on 32-bit platforms, you know…
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.
Yes. These interfaces are provided on 32b too.
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.
Ah, the concern was that the results wouldn't match the tolerance.
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.
No worries there; on 64b you get the Double implementation, so if it passes for Double it passes for CGFloat. On 32b, it's implemented by calling Double, then rounding to CGFloat, so if the Double implementation passed, the error of CGFloat is like < 0.50000003 ulp at worst.
Build failed |
... instead of marking them obsoleted, since the replacement is transparent to the user. Also fix a spelling error.
@swift-ci Please smoke test. |
These changes bring CGFloat in line with the other FloatingPoint types. Some of this stuff is now defined at the protocol level, so we can get rid of it at the concrete type level, with an obsoleted message. A couple other functions have been deprecated for all types, with protocol or tgmath replacements.