[swift-corelibs-dev] Foundation and NSDecimal

[Kenny Leung]

I would also say that this should not be marked as @discardableResult, since its only purpose is to report back yes or no, it would be kind of suspicious if the it wasn’t used.

-Kenny


> On Sep 27, 2016, at 5:34 AM, Alex Blewitt via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> The Framework function 
> 
> NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)
> 
> has been imported into Swift on both Darwin and Linux as
> 
> :type lookup NSDecimalIsNotANumber
> @discardableResult func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer<Foundation.Decimal>) -> Swift.Bool
> :type lookup NSDecimalIsNotANumber
> func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer<Foundation.Decimal>) -> Swift.Bool
> 
> However I think this should instead be imported as a member function on the Decimal type, instead of passing through a pointer.
> 
> extension Decimal {
>  public func isNotANumber() -> Bool
> }
> 
> This may not have been picked up by the automatic renaming progress because it's a const pointer, and because it's an NS_INLINE defined in the header, instead of in an implementation file.
> 
> There are some other global constants NSDecimalMaxSize and NSDecimalNoScale, which should probably be implemented as constants in the Decimal type as well e.g.
> 
> extension Decimal {
>  public let maxSize = 8
>  public let noScale =  Int16.max
> }
> 
> Since this would need to be fixed in both the Swift Linux foundation implementation and the Darwin overlay (and it would be a breaking change) what is the right process to be able to fix this?
> 
> Alex
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev