is there String.startsWith with startIndex: Int and regexp ?

I don't think so (it also would be weird naming, as regexp matching is something very different from

startsWith

)

Or you could incorporate it into the regex:

^.{startIndex}...

.

Is it possible to add "isOverridden" to https://github.com/JetBrains/kotlin/blob/master/core/builtins/src/kotlin/reflect/KCallable.kt ?

I don't think so, I assume the reflection mechanism works like it does in Java, where you can't know all of the subtypes of a type because classes are lazily loaded on the JVM. The only way around that is to write a classpath scanner, I believe.

I mean it has

override

on method, so "isOverridden" from child point of view, not from parent

oh you mean like, "is this an override of a supertype's method", not "is this overridden somewhere by a subtype"

yes

the advantages of a proper immutable collection over just using

List

backed by an

ArrayList

being the performance benefits? I'd use them wherever I'm currently using normal collections, though I assume the Java interop would be hairy so in those scenarios, I might revert back to the current "immutable-but-not-actually" collections

@kevinmost Regarding performance benefits, it's not so straightforward. Using the immutable collections usually implies performance trade-offs. For example, building an immutable persistent list element by element may be faster and require less memory than doing so with a readonly list, that require full copy for each element to be made, but way more slower than with a mutable list. An iteration through an immutable collection may be slower too.

that makes sense. Currently though, I think a lot of people (myself included) are using readonly lists for the sake of readability, and accepting the performance tradeoffs that come with that. I would still use mutable lists where I see fit, but I would probably replace most or all of my usage of readonly lists with immutable lists

Python gets this very wrong, I would love for some assurances to be made even as a library to allow for immutability all the way into the language. We had some client code in Python that would hand a dictionary to a plugin function, the plugin "could" make a mess of the dictionary and then throw an exception leaving the code in an invalid state unable to know how to roll back.

Its one of the main reasons I stopped using Python in favour of kotlin.

On my current project we use readonly lists and defensive copies in a number of places despite the performance cost, because it makes the behavior of both the callers and the callees more predictable, and protects them from the collections being unexpectedly modified. My understanding is that Clojure has immutable data structures that do significantly better performance-wise when the data is copied, with a minor overhead when looking up indices, so something like that would be what I would like to see from Kotlin’s immutable collections.

Also, as we speaking of trade-offs, there seems to be no one-size-fits-all

ArrayList

analogue in the land of immutable collections. The same ImmutableList interface can be backed by different data structures, providing different performance trade-offs. For example one can have fast add to the end, provide sequential accesss and reasonably fast indexed acccess, but at a cost of very expensive remove.

Hence I've started that survey to find the most common concrete use cases upon which we can base our decision what implementations to use by default.

Ahhhh, that helps to know. In the Android app I’m currently working on, most of our data structures are very small (< 10 items), and most of the mutation is adding items or groups of items to a list. Very little removal from lists. I think this describes the majority of my experience working on Android projects, the only time there are large lists is when we are deserializing them from server requests, which we typically don’t modify at all.

for the list, I think that indexed access is fairly important. I wouldn't mind giving up remove perf in favor of boosting random access perf

We have static lists that are used to in operator chaining like

map

or

forEach

these list need to be appended to mostly, but then used in operater chains. No removal though...

Also I guess immutable list concatenation comes up a lot in

flatMap

calls.

listOf(null).firstOrNull()

looks ambiguous. Shouldn't

*OrNull

operations be for

<T : Any>

?

It still does exactly what the name suggests, I think it's fine.

nullableCollection.*OrNull()

cannot be done right, this is a logical error. When you change your collection type to nullable, all *OrNull calls start working ambiguously, which I'd prefer to be warned about.

It doesn't start working ambiguously, it still does exactly what it suggests: return the first element and if there isn't one return

null

. It's true that you can't use the nullability of the return value to check whether the collection had a first element, but maybe that's not what you needed at all.

For

data class Todo(val id: Int, val todo: String, val completed: Boolean)

why does

Json.decodeValue(jsonStr, Todo::class.java)

not allow me to access the fields?

^ nvm bad import

import com.sun.tools.javac.comp.Todo

🤦

index-based for loop?

Yes,

mapIndexed

will work for me.

I wish Tuple's were still part of the language because each data class a user defines has a correspondent equivalence to one of the

TupleN

possible arities. Data classes could have had

.tupled

and

.fromTupled

as synthetic methods like they have now with

copy

allowing operations such as these kinds of zips to propagate directly to the target user defined data classes

It's double-edged though, right now you're basically forced to create data classes for each tuple you use, forcing you to name both the elements and the combination which is a good thing.