`macro customFor[T](a: T, b: ForLoopStmt): untyped = ...`

timotheecour commented 3 years ago

proposal

allow this: macro customFor[T](a: T, b: ForLoopStmt): untyped = ...

benefits

allows overloading based on type
this would allow UFCS/MCS with ForLoopStmt, which is currently not possible
```
import std/enumerate
for a in enumerate([1,2]): discard # ok
for a in [1,2].enumerate: discard # doesn't work
```
(ie would fix https://github.com/timotheecour/Nim/issues/473 but with a better solution)
we'd possibly be able to fix https://github.com/nim-lang/RFCs/issues/74 by making pairs, mpairs implemented via ForLoopStmt (which needs MCS + overloadability based on type to be a valid replacement)

background

originally proposed in https://github.com/nim-lang/RFCs/issues/332#issuecomment-778433560

note

this is probably not a breaking change
as mentioned in https://github.com/nim-lang/RFCs/issues/332#issuecomment-781895765 we should IMO also support macro customCase[T](a: T, b: CaseStmt): untyped = but that should be discussed separately. But the nice thing is the symmetry you'd get between case and for macros.
would fix https://github.com/nim-lang/Nim/issues/17797

Araq commented 3 years ago

Too unspecific. What would the spec contain? When is customFor considered inside Nim's for loop handling?

Varriount commented 3 years ago

Is this problem due to the limitations of method-call syntax?
If so, would it be possible to improve the resolution logic instead? That way, not only would for-loop macros benefit, but general usability would too.

timotheecour commented 3 years ago

If so, would it be possible to improve the resolution logic instead?

that's a separate issue; without the RFC you can't have overloading.

Is this problem due to the limitations of method-call syntax?

actually that section needs to be updated now that https://github.com/nim-lang/Nim/pull/17196 was merged; var info = something().toSeq now does work; and all templates that can take iterable instead of untyped also do work with MCS/UFCS. But again, untyped params are still problematic for MCS/UFCS and I can't think of a way to fix this because the problem is essentially ambiguous (outside of https://github.com/timotheecour/Nim/issues/630). In short, this RFC is a separate topic.

nim-lang / RFCs