3 ms·
This is a weird approach. They are essentially manually implementing the “yield return” functionality from c#. C# defines an interface IEnumerable<T> with a “
by joneholland 3y ago
This is a weird approach. They are essentially manually implementing the “yield return” functionality from c#.
C# defines an interface IEnumerable<T> with a “next” method, and originally you’d need to implement this interface which was a bit of boiler plate.
They added “yield return” which would create compiler generated syntax sugar to return a generator function like this go proposal, but your code looked identical to a non iterative version.
The go proposal feels like the worst of both worlds and like the team misunderstood the purpose.
- anonymoushn 3y agoThe proposal is more powerful than the C# "yield return" functionality because it allows the yield function to be passed to subroutines.
- jcparkyn 3y agoHow is that better than the C# solution of just making the subroutine return an IEnumerable, then yielding its elements in the calling function? (aside from maybe marginally better perf characteristics)?
- anonymoushn 3y agoIt works with subroutines that don't know anything about iterators or yielding but do know about first-class functions. It's also less boilerplate, since there isn't a `yield from`, I guess.
- agent281 3y agoIt seems like a different kind of boilerplate: instead the functions need to take a yield so you are threading the function through you program. I don't know if it's better to expect a return type or to force a function argument. I lean towards the former, but that might be because of familiarity.