Please vote on std.datetime

[Dmitry Olshansky]

On 10.12.2010 23:00, Jonathan M Davis wrote:
> [snip]
> Overall, I don't really see the benefit of your proposal. The main advantage of
> fwdRange and bwdRange in the interval types instead of just a single function is
> that they allow you to verify that you're iterating in the correct direction.
In my proposal it still checks this, what I meant is - there is no need 
to define them inside range,
in fact it's quite easy to define generic fwdRange, that works on any 
interval, which is what I did
  (it still lacks PopFirst.yes customabilty and such, but that can be 
easily fixed).

> Otherwise, you risk an infinite loop. If we were willing to forgoe that, then you
> could make it so that you only had one function, but I think that that would be
> a definite loss.
> It _is_ annoying to have to give Direction.fwd or Direction.bwd to the functions
> in IRange when you're feeding it to fwdRange or bwdRange since it does seem
> redundant, but those functions need to know what direction you want them to
> iterate in, and both fwdRange and bwdRange are designed for general delegates -
> not necessarily just those generated by IRange - so they assume the direction.
> But since the functions in IRange default to Direction.fwd and that's almost
> always what you'd want, I don't think that it's ultimately that big an issue.
Agreed, It's not a big issue. But I thought delegate can go back and 
forth as it's internal logic suggests, it's when it hits the end of 
interval that's important (and I assumed that would be the end of 
iteration).

> Conceptually, I think that it makes perfect sense that the interval would have
> the range functions on them - that's certainly what happens with containers. I
> don't see the benefit in splitting them out.

It's where we are disagreeing it seems. For me, the less monolithic the 
interval struct, the better.
After the interval provided begin and end (ether one), it's trivial to 
implement generic fwdRange and bwdRange outside, and  they also provide 
'contains' function.

> Your solution makes it so that a range is infinite separately from whether the
> interval is infinite. I don't think that that makes sense. A range is only
> infinite because it's iterating over something infinite. By making the range
> infinite separately, it's then possible to try and iterate infinitely over a non-
> infinite interval, which would be a problem.
>
For me the problem would be to iterate over infinite range assuming it's 
finite.

> For the most part, it looks like all you've done is try to make it so that the
> ranges are unrelated to the intervals that they iterate over. That seems like a
> bad idea to me, and I fail to see the benefit. What does your solution do that
> mine can't?
Delegate can generate range of seemingly unrelated time points, or for 
which you may not know the interval or it's pointless or hard to 
calculate.  Consider you need date of next 5 blue dragon years (that's 
that Chinese calendar thingy) ?
That's solvable,with a dummy infinite interval. My point is that when 
you need custom delegate, it's only for specific tasks, for which 
interval may not be interesting at all.

> My solution is completely generalized. You can use take() and all of those
> std.range and std.algorithm functions on the ranges in std.datetime. You can
> give it a delegate defined as you like as long is it takes a time point and
> returns a time point of the same type. If you got your range via fwdRange(),
> then the time point returned must be after the one given, and if you got your
> range via bwdRange(0, then the time point must be after the one given. It's
> fairly straightforward and not error-prone.
I can't take if I don't know the interval beforehand, or need to create 
a dummy infinite one. Or even worse delegate could produce time points 
in non-directed way, like consider +1 day, -2day, +3day (no, it's not 
common but... you are the one to talk about generalizations).

> I agree that the IRange functions are a bit ugly, but they're an attempt to make
> it easier to create common delegates to pass to fwdRange() and bwdRange() rather
> than you having to create your own. You don't have to use them. They're for
> convenience. And they include a function which generates a delegate which causes
> the range it iterate by a given duration every iteration: IRange.everyDuration!
> ().

Yes, there I suggest to introduce a shortcut, like
auto byDay = fwdRange(interval, dur!"days"(1));
auto byYear = fwdRange(interval, 1);  //months = 0, duration = dur!"days"(0)

I fear It's just a matter of taste.

> I'm certainly open to suggestions, but I don't understand what's broken about my
> solution that yours fixes. My seems fairly straightword.
>
> 1. You have an interval - be it infinite or finite.

There I thought is a problem in generalization , you may not know the 
interval.

> 2. You want a range, you pass a delegate (which determines how to iterate over
> the interval) to fwdRange() if you want to iterate forwards and bwdRange() if
> you want to iterate backwards. fwdRange() and bwdRange() verify that the
> delegates that you give the return time points which are valid for iterating
> over the interval (so, not duplicating the previous time point or iterating in
> the wrong direction).

Yes, that's check could be a good thing. In my proposal you'd get an 
empty range or infinite, still can be added, of course.

> 3. If you don't want to create your own delegate, then you use one of the
> functions in IRange to generate one for you.
> 4. Once you have your range, you can do whatever you normally do with input and
> forward ranges.

In fact, that's where the user need to get, and the easier the better.

> - Jonathan M Davis

-- 
Dmitry Olshansky