Is that Swift 6 feature something that could be done in Kotlin, within K2? https://x.com/arkann1985/status/1805721280244486241?t=e2yRkR8qg11zw56McrNYwA&s=19

Is there a proposal to support "overloads by return type"? Something that would allow the following to compile:

class A
class B

fun make():A = A()
fun make():B = B()


fun main() {
    val a:A = make()
    val b:B = make()
}

Are

Context Parameters

available for use yet? I'm currently using

Context Receivers

for some things, and found a show-stopping compiler bug with them.

It would be nice if this would work (especially for DSLs...):

val baz = "foo.bar"
var foo: String
var bar: String

// for assigning the vars, not new vals...
(foo, bar) = baz.split('.')

Does Jetbrains have a plan for multithreading with regards to Kotlin/Native?

Hey! During the migration of Dokka analysis to K2, several questions arose around KDoc links resolution. That's why there is a new KEEP (first of its kind) about KDoc! https://github.com/Kotlin/KEEP/issues/385

New KEEP about exposing boxed inline value classes in the JVM. Feedback is more than welcome!

Coming from scala miss so much tuples when working on kotlin, has there been disscussions about it? Scala also added support for named tuples which are the lambdas (annonymous/structural) counterpart for data classes instead of named/nominal, so they can be used as structural data types, while still being plain tuples as tuple names are erased

So, context parameters, nee receivers. I see that the compiler now says Experimental context receivers are deprecated and will be superseded by context parameters. Please don’t use context receivers. You can either pass parameters explicitly or use members with extensions. Passing parameters explicitly I understand, but what exactly is meant by use members with extensions? I would like if possible to maintain at least some of the structure that my existing context receivers gave in the interregnum during which neither context receivers nor context parameters will be supported

I read the blog post about "how I can contribute to Kotlin's future". There's one thing that I'd really like to see changed in Kotlin: it's handling of platform types. My team has been bitten too many times by platform types. Probably everyone who needs interop with Java code/libraries has had this problem. Now I dont mind that platform types exist, but I do mind that they are "treated as nonnull while they are certainly nullable". This is the biggest cause for NPEs that we find. IMHO a copmiler flag (like "warningsAsErrors") would be a good solutions, e.g. "treatPlatformTypesAsNullable". But maybe a compiler plugin could also be useful. On top of that we obviously also want the IDEA to follow along and give the right type hints. I'm not sure where to put this idea, should i create a KEEP for it? Or does anyone know if a similar proposal exists?

Hi! Here is the new KEEP about introduction of Common Atomic and Atomic Array types in the Kotlin standard library. Feedback is very welcome 🙂

New KEEP about nested (non-capturing) type aliases. This KEEP presents a way to have type aliases which live inside another classifier. As usual, feedback is more than welcome 🙂

I had an idea for KEEP and I wanted to know if it is viable or if someone has already proposed something similar I would like to propose the creation of

implement

statements, they would serve as an alternative way to create extension members

kt
class Foo {
 val bar = "hi"
}
implement Foo {
 val baz get() = "$bar, kotlin!" // would work like val Foo .baz get() = "$bar, kotlin!" 
}

syntax sugar for interface implementation wrappers for existing classes, when used in classes from other libraries

kt
class ExternalClass {
 val foo= "hi"
}

interface MyInterface {
 fun getText(): String
}

implement ExternalClass : MyInterface {
 override fun getText() = foo
}

// internally creates a wrapper
@JvmInline
value class MyInterfaceExternalClass(val value: ExternalClass) : MyInterface {
 override fun getText() = value.foo
}

// when ExternalClass is used in contexts that require MyInterface, internally the wrapper will be used, but in practice, you can use it as if it were actually ExternalClass

fun myFun(arg: MyInterface) {
 println(arg.getText())
}

val obj = ExternalClass()

myFun(obj) // prints "hi"

and for separating classes in multiple files, but uniting everything in a single class, when used in project classes

// a.kt
class Class {
 [...]
}

// b.kt
implement Class {
 [...]
}

// c.kt
implement Class : MyInterface {
 override fun getText() =randomValue
 [...]
}

in my opinion this would be viable and useful, what do you think?

Is there a status update on Context Receivers/Context Parameters in the 2.1.20-beta? Slack Conversation

New KEEP-409 on Subtyping Reconstruction is open for review. This KEEP presents the Subtyping Reconstruction technique that introduces smart casts for generics. This feature might be known to you as GADT. Any feedback is welcome

Hey folks I had an idea for predicated scope functions. Wondering if anyone has proposed these before or if they are a good candidate for a KEEP. The idea is to add

applyIf

,

applyUnless

,

alsoIf

, and

alsoUnless

to the standard lib. I chose

apply

and

also

among the various scope functions because these functions simply return the receiver object, so the return type can still be known regardless of the predicate. As a server developer, I use

applyIf

on builder objects quite frequently and my company has added it to an internal shared kotlin library. I suspect many kotlin devs use some version of this already. An example would be:

inline fun <T> T.applyIf(predicate: Boolean, f: T.() -> Unit) = apply {
  if (predicate) f()
}

val myPlanBuilder = MyPlan.newBuilder()

myObjectBuilder.applyIf(isSunnyOutside) {
  addPlanLineItem(goGetIceCream)
}

I've created a youtrack issue for suspend interfaces, an idea to fix Kotlin's code coloring using interfaces and functions that are compiled to have a suspending and a non-suspending variant, to avoid the ecosystem looking like Rust's, where the entire ecosystem is duplicated

Hi! We have a new KEEP to share with you — https://github.com/Kotlin/KEEP/issues/412. It is about enhancing the functionality of the existing 'unused expression' static analysis in the Kotlin compiler. New diagnostic should be able to report complex expressions whose return values are meaningful (e.g., non-Unit) but are not used.

Hello everyone! Happy to share a new KEEP-416 Collection literals. Collection literals is a syntactic construct that allows creating collection instances more concisely and effortlessly. As always, feedback is welcome!

Hi! I am not sure this is a right place to advertise my post, but I just opened https://youtrack.jetbrains.com/issue/KT-76846 to take opinions about "data object implicitly capturing properties". If you take a look and add some comments, I would appreciate it!

Recently, I used the RxJava method

Completable.doOnEvent

, which takes a lambda `(Throwable?) -> Unit`:

myCompletable.doOnEvent { doSomething() }

However, this started throwing exceptions. As it is a Java method, Kotlin automatically regarded

it

as

Throwable!

and therefore

Throwable

, and as soon as the lambda was called with a null value, it did a null check and threw a NPE, even though it was verifying a value that went completely unused. As the only reason Kotlin automatically treats

Throwable!

as

Throwable

here is for convenience, could it recognize in this case that the parameter is entirely unused, and therefore not overeagerly perform a null check? The solution to avoid the exception is to specify

{ _: Throwable? -> doSomething() }

, which I'd rather not need to specify, and I'd especially have preferred not to have to deal with the exception in the first place at all.

I just watched the presentation on the new Rich Errors language feature. Since

?

and

!!

will be used as well for error types, how are we going to differentiate between null and error in a function returning a nullable type?

fun foo() String? | SomeError

I was surprised this wasn’t addressed at all in the talk. Are we supposed to either write functions with error union types OR functions returning nullable without error union types? What about generics versions of this? A

null

can be a valid successful response

First-class generic functions (or Rank-N Polymorphism) This would allow passing generic functions around, and more importantly write generic lambdas. Existential types somewhat fit this hole already, but they have multiple issues, including brittle support by type inference, and the fact that there's no way to associate 2 parameters with each other without using a wrapper class. What I mean by that is that we can't give a type to the following function:

fun <T> add(first: T, second: T)

Nor this function:

context(t: T) fun <T> foo(list: MutableList<T>)

The public KEEP review for static members and type extensions is now open. We would love to hear your feeback! 🙂 (Feedback and discussion on the proposal happens here, feedback on the text itself happens here)

One more announcement: we’d like to try out the GitHub Discussions feature for KEEPs — https://github.com/Kotlin/KEEP/discussions. We’re doing this mainly because it allows for threaded discussions and a bit more structure. For now, we’ve moved only the statics proposal and want to see how it goes, so feel free to share your feedback here

The updated KEEP proposal for "Explicit backing fields" feature is open for review. Feel free to leave your feedback in the discussion!

Hello folks, the KEEP for version overloading proposal to improve binary compatibility of optional paramaters is now open for review. We would love to hear your feedback! PR: https://github.com/Kotlin/KEEP/pull/423 Discussion: https://github.com/Kotlin/KEEP/issues/424

Proposal: Platform Type Annotations While I do not think user specifiable platform types should be added to the language grammar, I occasionally run into instances (usually involving generics) where it would be nice if my Kotlin wrappers around platform code could specify they work with platform types, possibly using an annotation. Example in thread.

Proposal: side-effect free getters It's a pretty well-known problem that if you split a project into multiple modules, you lose some smart casting because the compiler cannot assume that a getter in another module will always return the same result. I'd like to propose adding an annotation that indicates that the library author intends for a getter to remain side-effect free so that clients can write code more naturally. Thoughts?

The KEEP for name-based and new positional-based destructuring is now open for public review https://github.com/Kotlin/KEEP/discussions/438