On Saturday, 28 December 2013 at 14:09:17 UTC, Joseph Rushton Wakeling wrote:
> Try the attached code.  The largest value of DateTime(2012, 1, 1) + dur!"days"(5
> * n) that is less than DateTime(2013, 1, 1) is _not_ DateTime(2013, 1, 1) -
> dur!"days"(5). :-)

OK, so this has nothing to do with leap years, but that 5.days is an improper step.

On Saturday, 28 December 2013 at 14:13:08 UTC, Francesco Cattoglio wrote:
> It's always the same "issue": you have to compute the last element inside iota, you should never rely on the user giving you ideal inputs.

Alright, so require division for bidirectionality when given a custom step. There's no reason division should be required for bidirectionality in the most common case of iota(start, end).

On 28/12/13 17:10, Jakob Ovrum wrote:
> OK, so this has nothing to do with leap years, but that 5.days is an improper step.

Oh, I see -- you're assuming that iota has to be defined with start, end and step such that end = start + (n * step) for some integer n >= 0.

I can see the case for it, but to me it seems like a too restrictive requirement.

On Saturday, 28 December 2013 at 16:30:27 UTC, Joseph Rushton Wakeling wrote:
> I can see the case for it, but to me it seems like a too restrictive requirement.

Yes, I can totally see that. I'm not really invested either way, because while I see a need for bidirectionality with `iota(start, end)`, it seems less useful with `iota(start, end, step)`.

On Saturday, 28 December 2013 at 16:13:45 UTC, Jakob Ovrum wrote:
> Alright, so require division for bidirectionality when given a custom step. There's no reason division should be required for bidirectionality in the most common case of iota(start, end).

Ok, now I finally get your point. It goes something along the lines of: "if no step is provided, then we can assume end can be reached by just stepping forward (incrementing by one)". It makes sense, but personally I don't like to make assumptions. I think assumptions in library code are one of the worst sources of nasty bugs in user code.

On Saturday, 28 December 2013 at 19:22:25 UTC, Francesco Cattoglio wrote:
> On Saturday, 28 December 2013 at 16:13:45 UTC, Jakob Ovrum wrote:
>> Alright, so require division for bidirectionality when given a custom step. There's no reason division should be required for bidirectionality in the most common case of iota(start, end).
>
> Ok, now I finally get your point. It goes something along the lines of: "if no step is provided, then we can assume end can be reached by just stepping forward (incrementing by one)". It makes sense, but personally I don't like to make assumptions. I think assumptions in library code are one of the worst sources of nasty bugs in user code.

As long as `start < end` is true in the beginning, that's a perfectly reasonable assumption to make, especially if "end can be reached" means `start >= end` is true after some `n` number of increments.

If we can't make any assumptions about the chosen concept primitives then they're no good as primitives at all.

On 27 Dec 2013 20:33, "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>
> On Wed, Dec 25, 2013 at 02:30:45PM +0000, Francesco Cattoglio wrote:
> > On Wednesday, 25 December 2013 at 10:58:53 UTC, bearophile wrote:
> [...]
> > >(A less important enhancement is issue 11252).
> > On the other hand, I have honestly no idea whatsoever about how to implement this
> [...]
>
> It should only be supported for numeric types (i.e., that support +, *, /). Here's a crude attempt at it:
>
>         struct Iota(S,T,U) {
>                 S start;
>                 T end;
>                 U step;
>
>                 ... // other stuff here
>
>                 bool opBinaryRight(string op)(V val)
>                         if (op=="in" &&
>                                 is(V.init < S.init) &&
>                                 is((V.init - S.init) % U.init) &&
>                                 is(T.init >= V.init))
>                 {
>                         if (val < start || val >= end)
>                                 return false;
>
>                         // Surprisingly, x%y actually appears to work
>                         // like fmod(x,y) in D for floating point types!
>                         // Not sure how to represent 0 in a generic way
>                         // though.
>                         return ((val - start) % step == 0);
>                 }
>         }
>

For GDC, 'appears to work like' gets turned into 'it calls' fmod(x, y) in
D.  :)