<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I agree that it makes perfect sense for NSDate to implement Strideable. I actually do that already in my extensions.</div><div class="">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).</div><div class="">This shouldn't be used for date computations (and here I could say the name is ambiguous), but for time computations.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 6 Dec 2015, at 08:01, Kevin Ballard via swift-corelibs-dev &lt;<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">


<title class=""></title>

<div class=""><div class="">On Sat, Dec 5, 2015, at 11:29 PM, Zachary Waldowski via swift-corelibs-dev wrote:<br class=""></div>
<blockquote type="cite" class=""><div class=""><pre style="white-space:pre-wrap;background-color:rgb(255, 255, 255);" class=""><blockquote type="cite" class="">It is simply not the case that *all* arithmetic on NSDates is incorrect unless it involves NSCalendar and NSDateComponents.<br class=""></blockquote></pre></div>
<div class="">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.<br class=""></div>
</blockquote><div class="">&nbsp;</div>
<div class="">This doesn't make sense.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">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.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">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.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">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.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">-Kevin Ballard</div>

<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=UNDxqBUDZDpZmPmXfIKeZ1UxMq-2BwsURX5ulfpb2jFAYRfOZOlq3eitMK9JPpnvcZhjahTFZ4hStBNoyI385lBWlyC0Zmc15eibFywOJTHBN9y-2FkGcsEqhE7tYqXTii7XE4PB1L4zcEjbbqrMKp8VLs53DqXtgS3n0XB72Hc9CTPZHryumPQoLLrpnhFS5n0CrIpAN9vHxRnTt6XsDiym-2FjPeQvOIzvC8oJ3XZETJjZ8-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>


_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></body></html>