[swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

[Stephen Canon]

> 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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/5f4f2541/attachment.html>