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

[Charlie Monroe]

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> 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/c787344f/attachment-0001.html>