Will never happen. Best you can hope for is new functions
https://github.com/golang/go/issues/61902
https://github.com/golang/go/issues/61900
https://github.com/golang/go/issues/61899
https://github.com/golang/go/issues/61898
Yes there are and a lot of the work is already done.
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?
> 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.
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
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())
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)
}
}
}
}
[1] http://wiki.c2.com/?BlubParadox [2] https://sac.edu/AcademicProgs/Business/ComputerScience/Pages...
This is why I'm despairing so much over Go's popularity after using C#/F# and Rust which have rich and idiomatic iterator APIs. Go implementation is plain ugly, flawed and, most of all, is going to be slow unless you write it in the most verbose way due to Go's compiler weakness.
There are languages that move us forward, Go sets us back by 20 years.
Take these things a little less personally. Live and let live. People think differently from you, and that's okay.
Instead, people shoehorn it into data processing and databases, the domain at which .NET is incomparably more adept due to performance primitives it offers, if we still talk high-level-ish languages with automatic memory management. Of course if there is no such requirement, there are many (like Zig, Rust and C++) systems programming languages that are better in every possible way at solving the task. And yet, we get Go and startups struggling to scale. But all the interesting problems in which Go is attempted to be applied to, where the solution, if successful, is despite Go not because of it, would have benefited from C#/F# which offer much better control and performance assurances, without having to fight the tool.
I have meticulously benchmarked Go in previous roles and also used Go as a load generator and with smart allocation strategies the language is quite fast. I think you're letting your emotions cloud your judgement but that's nothing new in PL discourse. There's no better way to bring out those that identify with/against programming languages than PL discourse.
See, I would not call Zig unexpressive. I've written a number of iteration structs in Zig, because it has true optionals this is easy, using them is just:
var iter = thing.iterateSomeWay();
while (iter.next()) |item| {
// do stuff
}
Also by not doing enough to make UNIX culture startups have a different opinion of Microsoft, instead of still doing M$ jokes.
The same kind of startups that won't have any qualms adopting Swift, or dealing with its current poor state on GNU/Linux.
By way of analogy, consider that almost any language is missing lots of features present in some other languages. For example, Go does not have inheritance. If I do not miss that feature while using it, that does not necessarily mean that I'm a Blub victim.
As for the chaining, yes I do miss filter and map but is again totally doable with vanilla slices (they just haven’t added those methods to the slices package).