A modern programming language that makes developers happier.

kotlinlang

is this a compiler bug?

```open class Parent(
    open val numbers: List<Int>
) {
    val sortedNumbers: List<Int> = numbers.sorted()
}

class Child(
    override val numbers: List<Int>
): Parent(numbers)

fun main() {
    println(Child(emptyList()).sortedNumbers)
}```
it fails with

```Exception in thread "main" java.lang.NullPointerException: Parameter specified as non-null is null: method kotlin.collections.CollectionsKt___CollectionsKt.sorted, parameter <this>
	at kotlin.collections.CollectionsKt___CollectionsKt.sorted(_Collections.kt)
	at Parent.<init>(Blah.kt:4)
	at Child.<init>(Blah.kt:9)
	at BlahKt.main(Blah.kt:12)
	at BlahKt.main(Blah.kt)```

no, it's expected with how initialization works :sad-panda:

this is equivalent to the Java
```public class Parent {
    private List&lt;Int&gt; numbers;
    private List&lt;Int&gt; sortedNumbers;
    public Parent(List&lt;Int&gt; numbers) {
        this.numbers = numbers;
        sortedNumbers = getNumbers().sorted();
    }
    public List&lt;Int&gt; getNumbers() {
        return numbers;
    }
    public final List&lt;Int&gt; getSortedNumbers() {
        return sortedNumbers;
    }
}

public final class Child extends Parent {
    private List&lt;Int&gt; numbers;
    public Child(List&lt;Int&gt; numbers) {
        super(numbers);
        this.numbers = numbers;
    }
    @Override
    public List&lt;Int&gt; getNumbers() {
        return numbers;
    }
}```

notice that the constructor of `Parent` uses the overridable `getNumbers`, and at that point during construction, the backing field `Child.numbers` is still `null`

`open val` with a backing field is almost always a mistake

and using anything potentially overridable in a constructor is always a mistake

in Java <https://wiki.sei.cmu.edu/confluence/display/java/MET05-J.+Ensure+that+constructors+do+not+call+overridable+methods> and the same advice in Kotlin