universal toSeq: works with UFCS; works with inline & closure iterators, and with iterables

[timotheecour]

• current sequtils.toSeq is limited: it can't be used in UFCS, and can't be used in a number of other contexts (eg iterables that are not iterators, or even when calling a proc that returns an iterator)
• this fixes all of this

See test cases for more details but here's the skinny:

iterator myIter1():auto{.inline.}= ...
iterator myIter2():int {.closure.} = ...

doAssert [1,2].toSeq == @[1,2]
doAssert @[1,2].toSeq == @[1,2]
doAssert myIter1.toSeq == @[1,2]
doAssert toSeq(myIter1) == @[1,2]
doAssert myIter2.toSeq == @[1,2]
doAssert toSeq(myIter2) == @[1,2]

proc myIter3():auto= ... # returns iterator int
proc myIter4(a:int):auto= ... # returns iterator int
doAssert myIter3().toSeq == @[1,2]
doAssert toSeq(myIter3()) == @[1,2]

doAssert myIter4(1).toSeq == @[1,2]
doAssert toSeq(myIter4(1)) == @[1,2]

# this is the only case that can't be used with UFCS as myIter5(1) has no type:
iterator myIter5(a:int):auto = ...
doAssert = toSeq(myIter5(3)) == @[1,2]

note

• the split between toSeq1 and toSeq2 is needed because of this bug [1]
• toSeq handles the remaining cases (where param must be untyped), eg: toSeq(myIter5(3)) with iterator myIter5(a:int):auto = ...

fixes

• makes test case in this work: Confusing error message when calling toSeq using a non-iterator Confusing error message when calling toSeq using a non-iterator #7182

links

• [1] for x in myIter(42)(): ... gives infinite loop; inconsistent with let it = iterGen(42); for x in it(): ... for x in myIter(1)(): ... gives infinite loop; inconsistent with let it = iterGen(1); for x in it(): ... #8775

[timotheecour]

/cc @Araq

[timotheecour]

/cc @Araq friendly ping

[Araq]

Sorry, PRs like these are delayed until finally we got 0.19 out.

[timotheecour]

/cc @Araq ping now that 0.19 is out

[timotheecour]

@Araq anything holding this back? there are 7 +1's and I'd really like to have this in

[krux02]

Generally I have to say, I like it. I think a toSeq that just works more often is very valuable. I just don't like the compiles directives. It might cause slow compilation, but I am not sure about it since I honestly think they are the best available option here. Let's see what Araq has to say. From me you get green light.

[Araq]

I think it's overly complicated and it will cause regressions.

[timotheecour]

I think it's overly complicated

not sure what you mean by that; implementation or user-facing API ?

if the latter, I have to disagree; I want a toSeq that "just works" in all contexts (or as many contexts as possible) ; and having it work in method call syntax (in all cases except 1 as mention in top msg) is also very valuable

if the former, I can try to see whether something can be simplified in implementation

it will cause regressions

impossible for me to disprove unless we implement (part of) #8638

[timotheecour]

@krux02 friendly ping (since @Araq assigned it to you)

[timotheecour]

@krux02 ping

[timotheecour]

/cc @Araq @krux02
should I rename the universal toSeq to toSeq2(or a name of your choice), leaving the original toSeq untouched, to alleviate any hypothetical concern you had about it will cause regressions so I can move forward with this PR? please...