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@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@swift.org
> 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
