[swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint
scanon at apple.com
Fri Jul 1 12:26:07 CDT 2016
> On Jul 1, 2016, at 1:20 PM, Erica Sadun <erica at ericasadun.com> wrote:
>> On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md <https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md> ]
>>> Just wondering, why no 'awayFromZero' case?
>> It’s not defined or required by IEEE 754. The others are. I wouldn’t be opposed to adding some other rounding modes, but the IEEE 754 set is as good as any as a starting point.
> I'm hearing a lot of "Wouldn't it be nice if"s, for items falling outside IEEE 754. Could we have a native Math module that offered such niceties under a separate umbrella proposal? Would it be too cluttery to allow things like Double.tau, etc via a Math.Double extension or however that might work?
I expect we will at some point in the future!
For constants specifically, while I would still want to keep them out of the top-level namespace on the types, I think it would make a lot of sense to have something like Double.Constant.xxx which could swallow pretty much anything that there’s a reasonable argument to justify.
We also wouldn’t want these to be a requirement of FloatingPoint, unless there were default implementations to *compute* all of them to full precision, to avoid placing too high of a burden on folks who want to conform to the protocol.
That would be pretty solidly in the “post swift 3” pile, however.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution