There're 2 different things here: 1) Implement an additional interface for an existing class using whatever syntax - not doable in a static language for JVM 2) Allow defining class members outside of the class definition - doable, use cases similar to partial classes in C#, will require more work on the proposal side (starting from extension vs member, probably just use some other syntax) and quite some additional support in tooling, so it needs strong enough motivation.

I'm not familiar with partial classes. Do they really provide much of a benefit over statically resolved extensions? The name sounds like it would be an encapsulation headache.

This feature would absolutely make Kotlin worse language than what it is now. I hope it won't get implemented. The most common use case for partial classes in C# is for auto-generated UI. I am 100% against adding this to Kotlin.

Interesting, thanks for the input

@poohbar , it would be interesting if you could give us more logical args instead of just your opinion.

I am against adding any features that would increase the probability of devs producing crap code. Splitting class implementation over multiple files results in hard-to-reason-about code. I like Kotlin because of its simplicity and limited number of features. If you want every possible bell and whistle anyone can think of, use Scala.