I doubt it will be a 1.3 feature. The status of the keep is still “under consideration” and there also is no prototype being developed yet.
Pity 
This was the most-wanted feature in JetBrain’s survey. There may be open/controversial questions with regards to the KEEP’s more advanced aspects, but the basic use case (which it calls the default) is pretty straight-forward.
The compiler already recognises collection literals (for the purpose of telling you that you’re not allowed to use them outside of annotations), it can process them in annotations, it would be nice if at least simplest part of the KEEP could be implemented in 1.3 - even if just an experimental feature.
1 Like
If you follow the KEEP discussion, you can see that it is really hard to find a good, general solution and that there are very strong arguments to drop this idea completely (as nice as it seems at first).
I did follow the KEEP discussion. That’s why I specifically referred to the “default” case - the simplest part of the proposal, covering 90% of the use cases, without all the difficulty entailed to solve the remaining 10% (which could come later if a good solution is found).
In the meantime, you could consider the fastutil collections. They are based on primitives and are quite extensive.
The issue becomes just how extensive as they must specialize on all primitives, and with things such as maps they specialize in the key, value, or both. For an Android app I took what I needed and compiled it directly into the app.
Something to consider. Not native Kotlin but I’ve had no interoperability issues, except you have to be careful in some particular areas such as calling getLong() from an iterator instead of get() which would cause boxing/unboxing.
disscusion moved to Collection literals : KT-43871 (jetbrains.com)