iter VS go-iterator

The reason why I decided on the inner/outer architecture was because interface objects can't be used as recievers to methods (as far as I understand). As a result, my initial implementation, which didn't have this structure, was limited to functions instead of methods, which made code where iterator methods were chained extremely unreadable, since it was difficult to tell which order they were being applied in. It's a tradeoff, but I think the readability might be worth it. Do you have any ideas for alternative workarounds?

I already played around a bit wit the beta a while back and made an iterator library to get to know this new language. It's here for anyone interested: https://github.com/polyfloyd/go-iterator

Regarding call chaining, it is still possible to chain things with operations that return different types, but they have to be done with functions instead of methods, so the result is still the same, just it's a little less readable. There is a generic iterator implementation by polyfloyd that doesn't support method chaining, but imo being able to chain iterators is one of their biggest strengths, since implementing lazy evaluation manually for a single operation isn't that difficult, its when you need to perform multiple kinds of manipulations that it gets messy.