answering Eric’s questions, using Java collections makes interop so much easier and more efficient that we have no plans to move away from that

as for collection plans, two things we plan in the near term is interop with Java 8 streams and Clojure-like persistent collections

and we will probably have collection literals at some point in some form

it’s also likely that we’ll add a few more library functions for idiomatic operations with collections

@yole: I understand the old docs are erased in order not to be confused with 1.0 My point is they were very helpful in understanding design decisions and evolution Maybe they may be placed in some ungoogleble location, or compiled to pdf and stored?

we definitely don’t want people to refer to random four-year-old comments for understanding the design of Kotlin1.0

a lot of the stuff written there no longer matches the current thinking of the team

especially given that the team is around and able to share the current thinking

if Kotlin becomes so famous that people become interested in a book like “Design and evolution of C++” but about Kotlin, we’ll be able to access that content simple smile

good point

points

Design and Evolution of C++ was a fascinating read 20 years ago, taught me tons of things about language design

Gave me a lot of respect for C++ too (which I already had at the time)

+1000 on Clojure-like persistent collections, @yole

@voddan: I wasn’t really trying to make a point, rather I was just musing about different library choices in the context of what had come before. If I were to make a point, it would be that the design of a stdlib should reflect the design features of the language it supports.

I would think that immutable collections should be left to mature in third party libraries for a while

I tend to agree with @andrewoma - I looked at them a bit, but so far I haven't really encountered parts of my code where I think, yes, what I really need here is an immutable collections library. The JDK's support for things like CopyOnWrite* has been sufficient

and the API is List<T> compatible, which is convenient. In practice, most of the lists where I want to be able to have stable views are not that large, so a simple copy is no big deal.

We have preliminary design for immutable collections, we left them post v1

would that build upon one of the existing persistent collection libraries (e.g. pcollections or jslang)? Or be an entirely new thing?

there was a new algorithm published some time during 2015 which is much more efficient than the existing immutable collections libraries. it's called CHAMP I think and it has a java implementation

so it'd make sense to adapt that, if such a library were to exist. but i'd hope it'd start out as a JetBrains supported add-on library for a while until being added to the standard library

oh that's nice! http://michael.steindorfer.name/publications/oopsla15.pdf

^ link about CHAMP

@ilya.gorbunov: ^

Missing feature(?): I want to count occurrences of a substring in a string. Kotlin offers the

"string".count(predicate: (Char) -> Boolean): Int

method. But if my substring contains more than one character, this approach won't work. ApacheCommons offers a

countMatches(str: CharSequence, sub: CharSequence): Int

method. It would be great to have an equivalent functionality in the Kotlin stdlib. Please correct me if the functionality is already given but i overlooked it. (see http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#countMatches(java.lang.CharSequence,%20java.lang.CharSequence) )

Couldn't you emulate this with a sliding window?

collection.sliding(3).filter { it = subString }

(approximate names)

you could if there was a ‘sliding’ function

I use currently the following approach:

fun String.countMatches(sub: String): Int {
  return (this.length - this.replace(sub, "").length) / sub.length;
}`