[swift-evolution] Feature proposal: Range operator with step

Thorsten Seitz tseitz42 at icloud.com
Wed Mar 30 10:35:13 CDT 2016

> Am 30.03.2016 um 05:58 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org>:
> 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

These views should of course be calendar aware, so striding by day does exactly that and not by some number of seconds or whatever?


> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list