Seems to me that anything with `-compare:` could conform to Comparable. The
list, however, is surprisingly short, and half bridge over to native Swift
types that are already Comparable:
- [NSDate compare:]
- [NSIndexPath compare:]
- [NSNumber compare:]
- [NSString compare:]
Looks like NSIndexPa
I also agree, since all methods already exist in NSDate. Conforming it to
Comparable and Strideable is just making interface more in line with Swift
spirit.
> On Dec 6, 2015, at 11:05 AM, Brent Royal-Gordon via swift-corelibs-dev
> wrote:
>
>> I agree that it makes perfect sense for NSDate to
> It is simply not the case that *all* arithmetic on NSDates is incorrect
> unless it involves NSCalendar and NSDateComponents.
But then the same logic would follow that String must have all sorts of
convenient but incorrect API on it, because it is simply not the case that all
character transfo
> NSDate (and dates/timestamps in general) is a poor choice for Strideable,
> because, DST.
> A Calendar using this interface for a repeating event would be broken using
> this. Or you would break anyone who really wants to iterate every fixed 86400
> seconds.
Sometimes you want to add an inter
> I think it's a good idea to conform NSDate to the Comparable protocol, so
> instead of using:
>
> if someDate.compare(today) == .OrderedAscending { }
>
> Developers can easily compare using compare dates using comparison operators:
>
> if someDate < today { }
I would also suggest we add Stri
