11 ms·

I’m using Go daily. Usually new features in Go are addressing some real need or pain point, or standardizing on something that’s become fragmented in the 3p eco

• MarkMarine 2y ago
  It’s called out in the proposal, but generics allow custom container types to be created like ordered map. Iterators allow nice methods to be created by designers of these containers types, and used in a way that is similar to the go collections like map and slice. Mentioned earlier in the comments, someone brought up in order tree traversal as well. I don’t see an issue having the for range syntax that works magically for go std lib containers extended to custom containers, especially since go std lib omits so many valuable containers
• skldj28d2 2y ago
  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.
• unscaled 2y ago
  This is the textbook definition of the Blub Paradox[1]. If you've mostly used Go (or moved to Go from JavaScript before it had iterators, or from Java where iterators are a royal PITA to write), it won't make sense. That's okay, since it is often hard to imagine how a feature will be used without getting used to it yourself. I'm pretty sure that most FORTRAN 66 developers coming to Go would be puzzled on why you need for loops at all, when you can write DO loops and specify the line number where the loops end (older Real Programmers[2] don't even understand why you need loops at all, since you can always GOTO anywhere you'd like). So to cut it short, iterators, as Go implements them, should be useful at least for the following cases: - Iterating over custom collections (e.g. trees, concurrent maps, queues) that are not provided by the language (and "range for" doesn't have custom code for inside the compiler). - Iterating over a collection in a different way, for instance filtering out some elements or iterating over the collection backwards (as in the giving example). - Reification - if abstract iterators can be passed to functions (instead of actual slices), you can write functions that operate on a theoretically infinite stream. - Chaining iterators. If iterators can be reified, you can also chain them together. This is somewhat cumbersome with the syntax Go 1.23 will offer, but in many languages you can write code like this: let incompatibleTransactions = user.Accounts .Filter(account -> account.Balance <= 0) .FlatMap(account -> account.PendingTransactions()) .Filter(tx -> !tx.AllowCredit()) Once you know what each function does, it is clear that the code goes through all the accounts that have a zero or negative balance and returns all the pending transactions that do not allow credit from these accounts. The equivalent imperative code is harder to figure out at first glance incompatibleTransactions := []Transaction{} for _, account := range user.Accounts { if account.Balance < 0 { for tx := range account.Transactions { if !tx.AllowCredit() { incompatibleTransactions = append(incompatibleTransactions, tx) } } } } If the accounts and transactions collections are not built-in the iteration code would even look worse. This code is harder to read since it conflates the What (what we want to achieve with the code) with the How (how to implement this with a for loop). Obviously, this is what imperative programming is all about, and Go is indeed becoming less imperative. [1] http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox [2] https://sac.edu/AcademicProgs/Business/ComputerScience/Pages/Hester_James/Real%20Programmer.htm https://sac.edu/AcademicProgs/Business/ComputerScience/Pages...
• sapling-ginger 2y ago
  You have never used for..range in Go? That's an iterator.
• phplovesong 2y ago
  The database driver has this row.Next() thingy that does not work with range.