Open timotheecour opened 3 years ago
Typo on title. Sounds useful for JS targets too. :+1:
I'd like to add that Python has two concepts for this: "iterable" and "iterator".
In pseudo-code:
type
Iterable[T, iT] = concept
iter(self: T): iT
Iterator[T, iT, vT] = concept of Iterable
iter(self: T): iT
next(self: T): vT
(Is it even possible to properly specify this using the current concept implementation?)
With this, all a for
loop needs to do is call iter
on its argument, and then repeatedly call next
on the returned iterator. This works because calling iter
on an iterable will just return the passed in iterable (it acts as the identity function).
A lot of APIs could benefit from the new
iterable
type (which accepts called iterators), but right now there's still 1 issue:iterable[T]
only accepts called iterators, not values (egseq[T]
).This proposal would allow a value
a
withitems(a)
defined on it to match againstiterable[T]
, in the same way thatfor
implicitly addsitems
:the implicit conversion would have lower priority than an explicit overload, eg:
explicit overloads are still useful in cases where you need extra information from the type, eg a
len
; but in many cases, the iteration is all you need and an overload doesn't add valuebenefits
avoids having to add need-less boilerplate that would require adding overloads for both iterable[T] and
Iterable[T]
where the latter is defined below:before RFC: requires boilerplate of adding
template bar(a: Iterable[int]): untyped = bar(items(a))
after RFC:
note 1
this would cause infinite loop in compiler, and even if it were fixed, would be a worse solution as converters have a more subversive side effect on type system
links