Golang

2163 readers

1 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

Posts must be relevant to Go
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

founded 1 year ago

MODERATORS

Ategon@programming.dev

RandomDevOpsDude@programming.dev

austin@programming.dev

Questioning Go's range-over-func Proposal (rulmer.xyz)

submitted 7 months ago by codesoap@feddit.de to c/golang@programming.dev

2 comments fedilink hide all child comments

I've seen that a new "range-over-func" experiment is available with Go 1.22. In this article, I took a closer look and evaluated the feature for myself.

you are viewing a single comment's thread
view the rest of the comments

[–] codesoap@feddit.de -1 points 7 months ago

Thanks for sharing your opinion with me!

What I'm hearing is basically "you don't understand the real benefits, so your not qualified to judge the proposal". I find this attitude quite harmful. If you think, I'm missing something important, please tell me about it. You will only convince me with arguments, not by patronizing me. Could you at least link the mentioned discussion?

There are plenty of containers [...] could also use a generic way of iterating over them.

To me, it seemed intended, that Go only has two first-level containers (slices and maps). It forces a certain amount of "uniformity" by giving other containers a disadvantage. Of course, in some scenarios you really need a different container and it will be more cumbersome to use, but it is by no means impossible without range-over-func.