I agree, but I'm not sure where that's coming from. It seems to be being
imported from CoreFoundation on Darwin, and although it's defined this way in
NSDecimal.h in the Foundation framework:
NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)
{ return ((dcm->_length == 0) && dcm->_isNegative); }
I'm not sure why the @discardableResult attribute is being added here; perhaps
it's to do with the fact that it's an NS_INLINE function. Should I raise a
separate bug for that?
Alex
> On 28 Sep 2016, at 17:32, Kenny Leung via swift-corelibs-dev
> <swift-corelibs-dev@swift.org> wrote:
>
> 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
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
