[swift-corelibs-dev] Suggested DateInterval API improvement

[David Hart]

I vote for (2). Thats what I would have expected. `start` changing from under you is weird.

> On 21 Jun 2016, at 18:44, Tony Parker via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> Hi Greg,
> 
>> On Jun 20, 2016, at 9:04 PM, Greg Titus <greg at omnigroup.com <mailto:greg at omnigroup.com>> wrote:
>> 
>> One domain where this happens is project planning back from a fixed end date. The most well-known of these would be rocket launches: “T minus 10 seconds” is exactly a negative time interval from an end date.
>> 
> 
> That makes sense.
> 
> Let’s say we added negative interval support to the type. I could see it working in two ways:
> 
> 1. You initialize with a start and negative duration. After this, the ‘end’ property becomes what you used for ‘start’ and ‘start’ is adjusted according to the interval.
> 2. We keep the start date to always be what you passed in but allow a negative value for timeInterval and allow for end to be < start.
> 
> Which of these would be the least confusing?
> 
> - Tony
> 
>> That being said, it’s a fairly uncommon use case and I wouldn’t change the API to support it on an equivalent basis with normal forward date intervals. A separate specific initializer for it might be useful, though.
>> 
>> 	- Greg
>> 
>>> On Jun 20, 2016, at 4:12 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>> 
>>> Hi Dave,
>>> 
>>> We had some extensive discussion about this ourselves, but we couldn’t come up with a compelling use case for a negative time interval. Can you describe how you wanted to use it?
>>> 
>>> - Tony
>>> 
>>>> On Jun 17, 2016, at 2:01 PM, Dave Lyon via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>>> 
>>>> In attempting to use the new DateInterval value type to improve some existing code, I ran in to an issue where DateIntervals cannot be "reverse" intervals, which is contrary to how TimeInterval works, and somewhat confusing.
>>>> 
>>>> I would propose that the DateInterval value type should be able to be properly initialized with any TimeInterval, as a reference date and time interval are all that is actually required in order to construct a DateInterval properly.
>>>> 
>>>> The simplest solution might be to change the `startDate:interval:` initializer to one allows for negative time intervals, such as:
>>>> 
>>>> public init(withInterval: TimeInterval, fromDate: Date) { 
>>>>     self.start = Date(timeInterval: interval, since: fromDate)
>>>>     self.duration = abs(interval)
>>>> }
>>>> 
>>>> I believe in general it is preferable to avoid preconditions that require a subset of a given input type (in this case, that TimeInterval be positive or 0), and would prefer to see an API where invalid values are properly converted from the given input to the documented output. E.g. the old “Be generous with input, strict with output” idea.
>>>> 
>>>> I hope this is the right place to bring this up, but if not I’m happy to move the conversation to Radar or elsewhere.
>>>> 
>>>> Thanks!
>>>> 
>>>> _______________________________________________
>>>> swift-corelibs-dev mailing list
>>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>> 
>>> _______________________________________________
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160621/de30727c/attachment.html>