Re: [swift-corelibs-dev] Foundation and NSDecimal

[Alex Blewitt via swift-corelibs-dev]

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 
>  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 
>>  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) -> Swift.Bool
>> :type lookup NSDecimalIsNotANumber
>> func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer) 
>> -> 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

Re: [swift-corelibs-dev] Foundation and NSDecimal

[Kenny Leung via swift-corelibs-dev]

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 
>  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) -> Swift.Bool
> :type lookup NSDecimalIsNotANumber
> func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer) -> 
> 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