[swift-corelibs-dev] [swift-evolution] Proposal: Conforming NSDate to Comparable
me at alexkolov.com
Sun Dec 6 06:48:43 CST 2015
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 <swift-corelibs-dev at swift.org> wrote:
>> 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.
> I obviously agree. But I’d also add that it might make sense to emit a compiler warning for things that look like date math instead of time math—for instance, constants divisible by 86400 (24 hours), or maybe even 3600 (60 minutes).
> Actually, this might be a good idea even when no time APIs are obviously involved. What are the chances your literal 86400 doesn’t have something to do with a date?
> Brent Royal-Gordon
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
More information about the swift-corelibs-dev