> On Apr 22, 2016, at 11:29 AM, David Sweeris <[email protected]> wrote:
>
>> On Apr 22, 2016, at 9:56 AM, Stephen Canon via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Naive question: is it necessary to make a trade-off here? Why not an
>>> associated type Exponent that's Int for Float, Double, and Float80,
>>> allowing for something else for bignums?
>>
>> It’s an added (fairly minor) complexity to the API surface that confers
>> approximately zero benefit.
>
> So you admit the benefit isn’t *actually* zero? :-)
>
> Yes, it does add a small bit of complexity to the API’s surface, but it's on
> a part of the surface that I don’t think people look at very much. How often
> are people extracting a float’s exponent? Plus, I suspect there’s a fair bit
> of overlap between the group of people who even know what `.exponent` would
> get used for, and those who’d get a warm fuzzy feeling from seeing that the
> standard library has baked-in, low-level support for bignum / arbitrary
> precision types.
>
> Embrace the warm fuzzies… make exponent be an associated type.
>
> - Dave Sweeris (who, despite the light-hearted tone, thinks this is actually
> pretty important)
The current design does not prevent bignum / arbitrary precision types. It
prevents soft-float types with ridiculously large exponent ranges, but such
enormous numbers are generally better modeled by either a logarithmic number
system or level-index arithmetic.
Making exponent an associated type makes implementing any future heterogeneous
operations (including generic conversions) more complex. This is a real cost,
for a dubious theoretical benefit.
– Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
