Issue 6447 & 10762: support user-defined types in iota()

[quickfur]

Fixes: https://issues.dlang.org/show_bug.cgi?id=6447
Partially fixes: https://issues.dlang.org/show_bug.cgi?id=10762

Basically, as long as a type supports comparison via < and incrementing via ++, iota should work.

This is an initial stab at issue 10762; it provides the baseline for the most general user-defined types, so the returned range for non-built-in types will only be input ranges. Subsequent PRs will gradually refine this, e.g., to support random access if x + y*k is a supported operation in the underlying type.

[PetarKirov]

Maybe it's a bit of an overkill, but have you considered using begin != end when opCmp is not available for the common type? For example in C++, != is used predominantly for iterators. I may be wrong, but I think equality is a more generic relation (or at least easier to support).

[PetarKirov]

Apart from that, LGTM. I especially find the documentation more readable now 👍

[quickfur]

I did consider using begin != end but decided against it in case the user type in question is a custom float and you're trying to do iota(1.0, 2.5), so begin != end will never be true.

[quickfur]

One alternative is to use < when it's available, but fall back to != otherwise.

[PetarKirov]

in case the user type in question is a custom float

That's a good point. Though, I think that if your are using custom floats you may accumulate a larger error with this version, than with specialized one, which directly returns start + step * index in front() (index is an integer), instead of incrementing start.

One alternative is to use < when it's available, but fall back to != otherwise.

OK, let's use != only as a fall back.

[quickfur]

Well, the idea is that this is just the most general, basic implementation. Later on, the plan is to extend it to take advantage of types that provide multiplication -- not only that will eliminate accumulation of roundoff errors, it will also allow us to return a random-access range instead of just an input range.

[quickfur]

There's also the case of detecting when a type supports +=, and allowing the step parameter in that case.

[andralex]

this spells trouble if B.init is an rvalue

[andralex]

there was a pull request for lvalueInit

[quickfur]

Which PR was that?

[andralex]

what's with the failures?

[quickfur]

No idea, I saw outbuffer failures on somebody else's unrelated PR too. Some kind of intermittent bug that somehow slipped into the code maybe?

[quickfur]

Fixed to use ref.

[yebblies]

No idea, I saw outbuffer failures on somebody else's unrelated PR too. Some kind of intermittent bug that somehow slipped into the code maybe?

That was #2902

[quickfur]

Ah, so that's what it was.

[quickfur]

The autotester is now green. Anything else that needs to be fixed?

[andralex]

OK, that's a good first step. I keep on thinking we should define abstract algebra paraphernalia like isGroup, isMonoid, etc.

[andralex]

Auto-merge toggled on

[quickfur]

@andralex The problem with that is, some things can't be tested at compile-time, e.g., isAbelian can't be feasibly implemented without code introspection. Also, how would you categorize a type that supports ++x but not x+y?

[quickfur]

If we don't stick to abstract algebra, though, I suppose we could usefully have templates like isIncrementable, isAssignAddable, etc.. But I'd be hard-pressed to find use cases for most of these outside of iota.

[JakobOvrum]

But I'd be hard-pressed to find use cases for most of these outside of iota.

Although I'm not necessarily arguing for their inclusion, they would be useful for std.range.enumerate too (#1866).

[quickfur]

Hmm. Maybe it's worth adding, then. If nothing else, it would make the sig constraints more readable...