[swift-evolution] Feature proposal: Range operator with step
xiaodi.wu at gmail.com
Tue Mar 29 22:58:19 CDT 2016
On Tue, Mar 29, 2016 at 9:57 PM, Joe Groff via swift-evolution
<swift-evolution at swift.org> wrote:
>> On Mar 28, 2016, at 5:33 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>>> Floating-point seconds (as NSTimeIntervals) are the natural Strideable.Stride, but it's not particularly clear to me that you want 1 second to be a default stride. It's the default you would guess, but it's not actually a particularly useful default.
>>> Any fixed-time-period stride with dates is fraught with peril. Not every day is 24 hours, not every minute is 60 seconds, etc. Working with dates requires enough special domain knowledge that I think it'd be harmful to try to genericize numeric concepts over it.
>> While this is true, "ten seconds from now" is always ten seconds from now, and "seconds between date1 and date2" is always the same number of seconds. There is a basic level of time measurement and manipulation which is completely independent of time zones and calendars; that's what NSDate and NSTimeInterval represent. They are needed fairly often, and they are perfectly compatible with Strideable's semantics.
> Perhaps, but if you make Date strideable by seconds and automatically receive a bunch of utility methods based on that, then it becomes really tempting to abuse absolute time periods, or to accidentally misuse generic Strideable utilities instead of calendar-aware ones. We don't make String a sequence for similar reasons (though perhaps, by analogy to String, there could be `seconds`/`days`/`solarMonths`/`lunarMonths`/etc. views that are Strideable).
That could still encourage abuse, however. If people aren't going to
seek out calendar-aware utilities, they're unlikely to be rolling
their own ways of guarding against assumptions such as "24 hours from
now is tomorrow." It'd be astonishing to such a user to find out that
striding by day doesn't necessarily give you each successive calendar
day (which it can't be guaranteed to do if "day" is simply a shorthand
for 86,400 seconds). And with leap seconds in the picture, it is
impossible to increment by any unit greater than seconds while still
aligning with the calendar, since two minutes from some future date
and time could be 121 or 122 seconds away.
More information about the swift-evolution