[swift-corelibs-dev] [swift-evolution] Proposal: Conforming NSDate to Comparable

[Davide De Franceschi]

I agree that it makes perfect sense for NSDate to implement Strideable. I actually do that already in my extensions.
The concept of NSDate and NSTimeInterval fit with the concept, the chance of misusing it doesn't increase too much with more utilities as a developer either knows what it represent or it doesn't (if it doesn't search for it).
This shouldn't be used for date computations (and here I could say the name is ambiguous), but for time computations.

> On 6 Dec 2015, at 08:01, Kevin Ballard via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> On Sat, Dec 5, 2015, at 11:29 PM, Zachary Waldowski via swift-corelibs-dev wrote:
>>> 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 transformations are incorrect unless they involve Unicode translation. The standard libraries should not go out of their way to make flawed code look easy.
>  
> This doesn't make sense.
>  
> NSDate exists independently of calendars. It represents a point in time, no more, no less. It has no notion of days or hours or anything else larger than 1 second. It has methods to advance by a given interval, and to calculate an interval from two dates. It also has methods for comparing dates. All of this is perfectly valid and correct and using them is not flawed.
>  
> I can think of no reason why declaring conformance on NSDate for Comparable or Strideable should change any of this. All it does is provide the standardized API that calls through to the methods that already exist. Strideable and Comparable do not have any inherent notion of calendars either.
>  
> It's certainly true that it is an error for a programmer to add 86400 seconds to a given NSDate and expect to get the exact same time in the following day. But that holds true whether they're calling .advancedBy() or whether they're calling .dateByAddingTimeInterval(). And there's plenty of valid use-cases for performing arithmetic on dates beyond adding and subtracting days. If you want to do day calculations, by all means use NSCalendar. That's what it's for. But that shouldn't stop anyone else from doing their own time calculations using the standard API.
>  
> -Kevin Ballard
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151206/0d197586/attachment.html>