[swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

Charlie Monroe charlie at charliemonroe.net
Tue May 24 01:41:49 CDT 2016


Yes, but here, the rawValue is Int - in my code, the rawValue is NumberType, which IMHO makes more sense...

> On May 24, 2016, at 7:36 AM, David Sweeris <davesweeris at mac.com> wrote:
> 
> Sorry, I misspoke. I just meant define it like this:
> public enum IntegerSign<T: SignedIntegerType> : Int {
>     case Negative = -1
>     case Zero = 0
>     case Positive = 1
>     public var signum: T {
>         return T(self.rawValue.toIntMax())
>     }
> }
> 
> Although, come to think of it, I’m not sure if that’s an exact drop-in replacement for your code, since it’s `SignedIntegerType` instead of `SignedNumberType`
> 
> -Dave Sweeris
> 
>> On May 23, 2016, at 11:48 PM, Charlie Monroe <charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>> wrote:
>> 
>> Sure, that's a good idea, though I'd personally use the signum var, since using rawValue seems like a bit of an abuse of the fact the enum is defined this way and doesn't help readability of the code:
>> 
>> enum IntegerSign<NumberType: SignedNumberType>: RawRepresentable {
>> 
>>     case Negative
>>     case Zero
>>     case Positive
>>     
>>     init?(rawValue: NumberType) {
>>         if rawValue == -1 {
>>             self = .Negative
>>         } else if rawValue == 0 {
>>             self = .Zero
>>         } else if rawValue == 1 {
>>             self = .Positive
>>         } else {
>>             return nil
>>         }
>>     }
>>     
>>     var rawValue: NumberType {
>>         return self.signum
>>     }
>>     
>>     var signum: NumberType {
>>         switch self {
>>         case .Negative:
>>             return -1 as NumberType
>>         case .Zero:
>>             return 0 as NumberType
>>         case .Positive:
>>             return 1 as NumberType
>>         }
>>     }
>>     
>> }
>> 
>> extension SignedNumberType {
>>     var sign: IntegerSign<Self> {
>>         if self == 0 {
>>             return .Zero
>>         } else if self > 0 {
>>             return .Positive
>>         } else {
>>             return .Negative
>>         }
>>     }
>> }
>> 
>> 
>> 
>>> On May 24, 2016, at 6:09 AM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>>> 
>>> Can we make it RawRepresentable? That way signum can just return self.rawValue
>>> 
>>> Sent from my iPhone
>>> 
>>> On May 23, 2016, at 06:05, Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> The clean way would be to make it an enum with var signum that would return -1, 0, 1:
>>>> 
>>>> enum IntegerSign<NumberType: SignedNumberType> {
>>>> 
>>>>     case Negative
>>>>     case Zero
>>>>     case Positive
>>>> 	
>>>>     var signum: NumberType {
>>>>         switch self {
>>>>         case .Negative:
>>>>             return -1 as NumberType
>>>>         case .Zero:
>>>>             return 0 as NumberType
>>>>         case .Positive:
>>>>             return 1 as NumberType
>>>>         }
>>>>     }
>>>> 	
>>>> }
>>>> 
>>>> extension SignedNumberType {
>>>>     var sign: IntegerSign<Self> {
>>>>         if self == 0 {
>>>>             return .Zero
>>>>         } else if self > 0 {
>>>>             return .Positive
>>>>         } else {
>>>>             return .Negative
>>>>         }
>>>>     }
>>>> }
>>>> 
>>>> Charlie
>>>> 
>>>>> On May 23, 2016, at 9:29 AM, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> Could you give an example of this method’s usage? Surely your value is either positive, negative or zero already, so this method doesn’t return anything more useful.
>>>>> 
>>>>> In other words, anywhere that I might do this:
>>>>> 
>>>>> 	if myValue.sign > 0 { … }
>>>>> 
>>>>> I could just as easily do:
>>>>> 
>>>>> 	if myValue > 0 { … }
>>>>> 
>>>>> To the same end result surely? Unless I’m missing something it seems redundant.
>>>>> 
>>>>> If there is a use-case for this, would it make more sense to have the return type as an enum with cases for Positive, Negative and Zero?
>>>>> 
>>>>>> On 22 May 2016, at 08:07, Adam Nemecek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> Howdy,
>>>>>> I think that the SignedNumberType should implement a method called sign that will return -1 for negative numbers, 0 for 0 and 1 for positive numbers. This is similar to the signum method in e.g. Java and similarly called methods in other languages.
>>>>>> 
>>>>>> The implementation is fairly straight forward
>>>>>> 
>>>>>> extension SignedNumberType {
>>>>>>   var sign: Self {
>>>>>>     if self == 0 {
>>>>>>       return 0
>>>>>>     }
>>>>>>     else if self > 0 {
>>>>>>       return 1
>>>>>>     }
>>>>>>     return -1
>>>>>>   }
>>>>>> } 
>>>>>> 
>>>>>> I was trying to implement is without branching by doing (x > 0) - (x < 0) but I couldn't get the types right so I'm open to suggestions.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160524/dcab9226/attachment.html>


More information about the swift-evolution mailing list