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

[Dave Abrahams]

on Wed Mar 30 2016, Joe Groff <swift-evolution at swift.org> wrote:

>> On Mar 30, 2016, at 11:42 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Wed Mar 30 2016, Joe Groff <jgroff-AT-apple.com> wrote:
>> 
>
>>>> On Mar 30, 2016, at 8:50 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>>>> 
>>>> 
>>>> on Tue Mar 29 2016, Joe Groff <jgroff-AT-apple.com> 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).
>>>> 
>>>> Except that collections aren't Strideable.  A strideable type is a
>>>> value that has an implied unit of measure so that you can offset it
>>>> without reference to any collection.
>>> 
>>> Who said anything about collections?
>> 
>> That's what those views are.
>
> Sure, but I was making an analogy. String isn't a Collection by itself
> because operating on pieces of a string usually requires a lot of
> domain-specific knowledge, yet we provide Collection views that
> present it as a collection of user-chosen units. Date (IMO) shouldn't
> be Strideable for similar reasons, since correctly manipulating dates
> requires a lot of domain-specific knowledge, yet we could provide
> Strideable views of a Date that advances by user-selected intervals. 

Oh, you really do mean to create a Strideable (rather than a Collection)
view.  I didn't understand that at first, sorry.  There are lots of ways
to slice this problem.

-- 
Dave