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@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 > Architechies > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev _______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
