Sure, the syntax looks more terse than the usual Go syntax. That's unfortunate. But the author of the article does point at an important reason to do it like t

Sure, the syntax looks more terse than the usual Go syntax. That's unfortunate. But the author of the article does point at an important reason to do it like this: > Allow for clean-up with defer When the range syntax would be syntactic sugar for an iterator created as a local variable which handles the state somewhat like this: iter := Iterator{ Next: func() bool {...}, Current: func() T {...}, } for iter.Next() { loopvar := iter.Current() ... } then there's no way (in the current language) to call its clean-up function on panic, whereas it comes naturally in the current proposal. Since these are functions we rarely write, I don't think the syntax will be a problem in practice. Perhaps they could add Yield[T] type to the standard lib to reduce some of the func-iness. The only gripe people may have is when it turns out to be much less efficient than a regular range loop.