> On Jul 1, 2016, at 1:20 PM, Erica Sadun <er...@ericasadun.com> wrote:
>
>
>> On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
