3 ms·

I don't know much (anything..) about Kotlin, but surely that is a library issue and not a language issue - which could be quite easily rectified?

• V-2 11y ago
  Yes and no... This is part of their standard library, so from a practical point of view, it is a language issue. Easily? Proper implementation isn't so trivial, look what it takes for Guava: https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/FluentIterable.java https://code.google.com/p/guava-libraries/source/browse/guav... https://code.google.com/p/google-collections/source/browse/trunk/src/com/google/common/collect/Iterables.java https://code.google.com/p/google-collections/source/browse/t... https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/Iterators.java https://code.google.com/p/guava-libraries/source/browse/guav... Plus: * new (lazy) extension functions would be getting in the way of standard ones, you would need a paralel naming convention (perhaps one borrowed from LINQ, where map = select, filter = where, fold = aggregate and so on) and developers would still confuse one with another. * unless we agree on one canonical implementation, yours would be different than mine, easy to see how it could become a mess. If there is a better approach which removes these obstacles, someone let me know