[swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.
David Sweeris
davesweeris at mac.com
Tue May 24 00:36:45 CDT 2016
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> 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/21e7709d/attachment.html>
More information about the swift-evolution
mailing list