[swift-corelibs-dev] NSDecimal & NSDecimalNumber

[Tony Parker]

> On Dec 11, 2015, at 1:02 PM, Dan Thorpe <dan at blindingskies.com> wrote:
> 
> Thanks for the clarification Tony - and for reminding me of the primary goal r.e. API compatibility. :)
> 
> This may be better suited to swift-evolution or users list, but regarding fatalError do you have any techniques for testing this behavior? I was thinking about an internal try/throw/ layer (which would then be caught and trampolined to fatalError for the public APIs) so that it would be possible to write unit tests for the edge cases where there is a calculation error.
> 
> Cheers,
> Dan 

It’s a good question regarding the testability of fatalError paths. I think it would be really unfortunate if we had to write our own trampolines every place that we wanted to use it, but I’m not sure how else to verify the behavior if we don’t want to allow every test case to crash. Let’s raise the issue on the more general swift-users list and see if anyone has any ideas.

- Tony

> 
>> On 11 Dec 2015, at 19:00, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>> 
>> Hi Dan, Florian,
>> 
>> I agree with Philippe that NSDecimal is a particularly troublesome area in terms of how poorly the API is imported into Swift.
>> 
>> Since NSDecimal is already a value type, it may be possible to do something better here ourselves without worrying about the bridging problem. It would be an API change, however, so we should follow the swift-evolution process.
>> 
>> NSDecimalNumber would be more complicated, since it’s a class (and furthermore, a subclass of NSNumber).
>> 
>>> On Dec 11, 2015, at 4:58 AM, Dan Thorpe via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>> 
>>> I’d be really interested in working on a Swift decimal number type. I’ve done some work on this for a Money type here: https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal <https://github.com/danthorpe/Money/tree/development/Money/Shared/Decimal>
>>> 
>>> I agree that it’s best to start with NSDecimal, and that approach 2 would offer the most flexibility.
>>> 
>>> I have a few other thoughts regarding the number behaviors.
>>> 
>>> NSDecimal’s functions accept rounding mode parameters and return NSCalculationError but NSDecimalNumber accepts NSDecimalNumberBehavior parameter and throws NSExceptions. I’m not really sure what the reason for this discrepancy is and should a new Swift NSDecimal use NSDecimalNumberBehavior, but maintain backwards compatibility with default behaviors and defined rounding mode? 
>>> 
>> 
>> Our primary goal is API compatibility across platforms. It would be really unfortunate if a client of Foundation had to #ifdef their code to account for a platform difference.
>> 
>> That’s not to say we can’t improve things (as we do with every release), but compatibility requirements are a fact of life for a low level library like ours. Our clients appreciate it. =)
>> 
>>> Also, should a Swift NSDecimal continues with raising NSException, or adopt Swift style error handling? I don’t think we would want to introduce try/throw/catch semantics into the publicly exposed methods - but we could have an internal API layer which does. Backwards compatible functions would then have to convert between Swift ErrorType and NSException or NSCalculationError.
>>> 
>> 
>> Anywhere that Darwin Foundation raises an NSException, we are replacing with fatalError, precondition, or similar. The root cause of either is the same (a programmer error). The try/catch/throws mechanism is for errors that we may want to present to a user at some point.
>> 
>> Hope this helps,
>> - Tony
>> 
>>> Cheers,
>>> Dan
>>> 
>>> p.s. in the linked project, I made a DecimalNumberType protocol generic over the Behavior, which I’m not entire sure was a good decision or not.
>>> 
>>> 
>>>> On 11 Dec 2015, at 12:32, Florian Reinhart via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Is someone already working on NSDecimal and/or NSDecimalNumber? If not I would like to help and have a few questions on how to best tackle this.
>>>> 
>>>> I think it’s best to start with NSDecimal and then use NSDecimal to create NSDecimalNumber. That’s why I want to concentrate on NSDecimal first. As far as I know there is no CF type we can utilize for NSDecimal and the existing interface is not Swift-like. I see two possible approaches here:
>>>> We try to match the existing interface of NSDecimal as close as possible and only provide the same function interface with UnsafePointers all over the place
>>>> We create a Swift-like version of the NSDecimal struct. This struct stores its data in private properties and exposes methods (add, multiply, etc.) and computed properties (isNaN, etc.). Additionally, to achieve compatibility with the existing Foundation NSDecimal, we provide the same functions that take NSDecimal pointers and internally use the methods of the Swift struct.
>>>> What do you think?
>>>> 
>>>> Unfortunately, I haven’t found a lot of documentation for NSDecimal, yet. Is there any documentation, which describes the NSDecimal functions?
>>>> 
>>>> —Florian
>>>> 
>>>> _______________________________________________
>>>> swift-corelibs-dev mailing list
>>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>> 
>>>  _______________________________________________
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151211/ac3de0f4/attachment.html>