6 ms·

Basically every custom data structure right now has some custom implementation of iterators. This will set a standard and make them usable with range loops. Eve

Basically every custom data structure right now has some custom implementation of iterators. This will set a standard and make them usable with range loops. Even simple library methods like scanner.Scan, strings.Split, regex.FindAll or sql.Query should return iterators.

38 2y ago
> scanner.Scan, strings.Split, regex.FindAll or sql.Query should return iterators Will never happen. Best you can hope for is new functions
- skldj28d2 2y ago
  I know. There are already proposals to add new functions to many of these packages that return iterators.
  - 38 2y ago
    no there arent
    - skldj28d2 2y ago
      https://github.com/golang/go/issues/61901 https://github.com/golang/go/issues/61901 https://github.com/golang/go/issues/61902 https://github.com/golang/go/issues/61902 https://github.com/golang/go/issues/61900 https://github.com/golang/go/issues/61900 https://github.com/golang/go/issues/61899 https://github.com/golang/go/issues/61899 https://github.com/golang/go/issues/61898 https://github.com/golang/go/issues/61898 Yes there are and a lot of the work is already done.
      - 38 2y ago
        thanks :) https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_Law%22 https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_L...
tapirl 2y ago
But is this a problem?
klabb3 2y ago
> strings.Split, regex.FindAll But they already do, slices are iterables, and the input is bounded. Plus you have lots of other benefits like indexability. What need would it solve? > scanner.Scan, sql.Query Right, these are not suitable for slices because they’re unbounded. But still, what’s the use case? You still have roughly the same amount of code, no? Even the same noisy if err != nil checks. Can you provide a snippet that highlights the benefits?
- Zababa 2y ago
  https://github.com/golang/go/issues/61405#issuecomment-1638896606 https://github.com/golang/go/issues/61405#issuecomment-16388...: > Can you provide more motivation for range over functions? > If the results can be generated one at a time, then a representation that allows iterating over them scales better than returning an entire slice. We do not have a standard signature for functions that represent this iteration. Adding support for functions in range would both define a standard signature and provide a real benefit that would encourage its use. > There are also functions we were reluctant to provide in slices form that probably deserve to be added in iterator form. For example, there should be a strings.Lines(text) that iterates over the lines in a text.

38 2y ago

> scanner.Scan, strings.Split, regex.FindAll or sql.Query should return iterators Will never happen. Best you can hope for is new functions

skldj28d2 2y ago
I know. There are already proposals to add new functions to many of these packages that return iterators.
- 38 2y ago
  no there arent
  - skldj28d2 2y ago
    https://github.com/golang/go/issues/61901 https://github.com/golang/go/issues/61901 https://github.com/golang/go/issues/61902 https://github.com/golang/go/issues/61902 https://github.com/golang/go/issues/61900 https://github.com/golang/go/issues/61900 https://github.com/golang/go/issues/61899 https://github.com/golang/go/issues/61899 https://github.com/golang/go/issues/61898 https://github.com/golang/go/issues/61898 Yes there are and a lot of the work is already done.
    - 38 2y ago
      thanks :) https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_Law%22 https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_L...

tapirl 2y ago

But is this a problem?

klabb3 2y ago

> strings.Split, regex.FindAll But they already do, slices are iterables, and the input is bounded. Plus you have lots of other benefits like indexability. What need would it solve? > scanner.Scan, sql.Query Right, these are not suitable for slices because they’re unbounded. But still, what’s the use case? You still have roughly the same amount of code, no? Even the same noisy if err != nil checks. Can you provide a snippet that highlights the benefits?

Zababa 2y ago
https://github.com/golang/go/issues/61405#issuecomment-1638896606 https://github.com/golang/go/issues/61405#issuecomment-16388...: > Can you provide more motivation for range over functions? > If the results can be generated one at a time, then a representation that allows iterating over them scales better than returning an entire slice. We do not have a standard signature for functions that represent this iteration. Adding support for functions in range would both define a standard signature and provide a real benefit that would encourage its use. > There are also functions we were reluctant to provide in slices form that probably deserve to be added in iterator form. For example, there should be a strings.Lines(text) that iterates over the lines in a text.