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@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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@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@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
