http://d.puremagic.com/issues/show_bug.cgi?id=9550
--- Comment #3 from [email protected] 2013-02-20 01:15:30 PST --- (In reply to comment #2) > (In reply to comment #1) > > Isn't what you are asking for a special case of sequence that discards any > > and > > all input? > > > > //---- > > int fun(T)(T/+Tuple!()+/, uint n) > > { > > static int i; > > return ++++i; > > } > > > > void main() > > { > > auto a = sequence!fun(); > > writeln(a.take(10)); > > } > > //---- > > [2, 4, 6, 8, 10, 12, 14, 16, 18, 20] > > //---- > > > > In this case "T" is a tuple containing the empty state, and n is the > > iteration > > count. > > > > Apart from the fancy sig, it's what you are asking for. > > > > Given that the signature of "fun" isn't specified yet, we could special case > > sequence for sequences that have no initial state, to simply call fun(n) (as > > well as be more efficient). > > > > I think it would be a good idea. So I'll look into doing that. PS: could you > > link the mentioned discussion, it could help. > > Granted, that is what I'm asking for, but it seems as hackish (if not more > confusing) then the iota solution. > > The sequence solution does not sound very intuitive given the fact the output > would change on each retrieval/take from the range. > > The discussions have been over a many conversations, as I have run into this > problem several times now, and finally resolved it isn't just something I have > missed in phobos. FYI, sequence caches it's result, so if you just call front twice in a row, you *won't* get different values for each front. map *doesn't* cache its result, so you *will* get different results if you call front twice in a row. As for intuitiveness, I personally prefer "sequence" over "map", but that may be because I actually use sequence and recurrence, so I'm more used to it. A third alternative you could use is, instead of iota, you may want to consider using repeat: //---- int fun(int) { static int i; return ++++i; } void main() { auto a = repeat(0).map!fun(); writeln(a.take(10)); } //---- The "advantage" this approach is that you define the range *mechanics* (repeat+map) first, and then build the bounds on top of that (take). Since take is infinite, there are chances it'll run faster too (operations such as length/empty will be easier to compute, since carried by the "top", as opposed to the "bottom"). //-------- But enough off-topic. You opened an enhancement request. Could you maybe formalize your need a bit more, tell us in more detail what the semantics of the range you are trying to build are? How you would use such a range? This would help us better address the issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
