On Thursday, 4 August 2022 at 21:31:02 UTC, Paul Backus wrote:
> Strictly speaking, you don't even need that; all you need is a range that generates the natural numbers, and you can write
>
>     naturals.take(n)
>
> ...to get the equivalent of iota(n).
>
> That said, I don't think you have to aim for total minimalism to avoid generality creep here. You just need to know what iota's purpose for inclusion is, so that you can say "no, that's not iota's job; use generate/recurrence/something else instead" when someone proposes an overly-general enhancement.

I agree!  It's like rangeTo and downTo in Kotlin, right?  The simpler, the better!

SDB@79

On Friday, 5 August 2022 at 00:56:04 UTC, Paul Backus wrote:
> On Thursday, 4 August 2022 at 22:36:57 UTC, H. S. Teoh wrote:
>>
>> Perhaps.  But the question now is, where do we go from here?  How do we improve what we currently have?
>
> Phobos v2, I guess? Leave the problematic overloads behind, and tell people upgrading to use a different function if they need something fancier.
>
> Unless there's been a big policy reversal announced at DConf, my impression is that breaking changes to existing Phobos interfaces are off the table.

There is probably a balance here between simple low level constructions but at the same time a convenient high level API. As a user, I would just much rather be able to do something like `x.iota(a, b)` where `x` could be anything that it might make sense to call `iota` on (I like "Design by Introspection" with a bit of duck typing thrown in).

The issue with something like `iota(n).map!(i => MyType.startValue + i)` is that I might have to write that all the time as a user. From my perspective, I would rather put an `iota` overload in `MyType`'s module if I can't have it as part of `phobos`. From this perspective, `std.algorithm` should support built-in types and other types could define their own `iota` that call these.

On Sat, Aug 06, 2022 at 03:11:28PM +0000, Paul Backus via Digitalmars-d wrote:
> On Friday, 5 August 2022 at 15:31:18 UTC, Steven Schveighoffer wrote:
> > As for working with arbitrary types, I don't see a problem with it. If you define ++ on your type or += 1, and it doesn't mean the same as every other type that defines that, then it's on you for not following the conventions. D is a language which uses the introspected abilities of things to define whether they are compatible.
> 
> One of the problems with `iota` is that, because it was built up by accretion of special cases, it does *not* adhere to any kind of consistent structural interface.
> 
> For example, this works:
> 
>     iota(BigInt(1), BigInt(10))
> 
> ...but this does not:
> 
>     iota(BigInt(1), BigInt(10), BigInt(1))
> 
> ...because nobody ever bothered to add a `(start, end, step)` overload
> for custom types.

Perhaps what we need is to sit down and come up with a consistent model for iota and implement that. A consistent API of what is expected of incoming types and how iota will behave in each case.

Here's a first stab at it. Let T be the incoming type (I'm leaning against separately parametrizing the start/end/increment types, I think that's just needlessly complex). Then:

0. T must at least support < and at least one of ++, +. If not, iota(T)
   is not supported.

1. If T supports ++, then iota(start,end) will return at least an input
   range.

2. If `T + int` is valid, then iota(start,end) will return at least a
   random-access range.

3. If `T + T` is valid, then iota(start,end,step) will return at least
   an input range.

4. If `T + int*T` is valid, then iota(start,end,step) will return a
   random-access range.


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?