[swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.
Charlie Monroe
charlie at charliemonroe.net
Wed May 25 06:06:20 CDT 2016
Ok, how about this? The compiler currently crashes when compiling this, but IMHO it is (or should be) valid code.
enum IntegerSign<NumberType: SignedNumberType>: NumberType {
case Negative = -1
case Zero = 0
case Positive = 1
var signum: NumberType {
return self.rawValue
}
}
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 8:48 PM, David Sweeris <davesweeris at mac.com> wrote:
>
> The RawValue is an Int, but signum is a T, which I thought was the point. I tried saying `T: IntegerLiteralConvertible`, and making RawValue = T, but the playground didn’t like that. Maybe with some of Swift 3’s generic enhancements, it could be that simple.
>
> In any case, it sounds like this might be a moot point… I was hoping raw values could be exploited to simplify the code, but if it can’t work, it can’t work.
>
> - Dave Sweeris
>
>> On May 24, 2016, at 1:41 AM, Charlie Monroe <charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>> wrote:
>>
>> 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 <mailto: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/20160525/759ba6ff/attachment.html>
More information about the swift-evolution
mailing list