With context parameters, how would one access a parameter if there are multiple parameters of the same type in a lambda?

fun foo(content: context(String, String) () -> Unit) {
    content("", "")
}

fun test() {
    foo {
        // Does not work: Multiple potential context arguments for 'String' in scope.
        implicit<String>()
    }
}

Is there any discussion around "import on demand" from objects? Constants.kt:

package foo.bar

data object Constants {
    val first = 1
    val second = 2
}

Main.kt

import foo.bar.Constants.*

fun main() {
   println("$first is first. $second is second.")
}

Question: are there any plans to make it so that you can have something that is abstract but can have a subclass with value class semantics? Something like an "integers mod n" class, for example.

Is it a valid statement to say that with context parameters you can actually recreate the suspend keyword? I mean, the suspend keyword provides a Continuation, but with context parameters you can provide a Continuation context.

TIL about Swift

async let

and I really want it: https://blog.yoshuawuyts.com/automatic-interleaving-of-high-level-concurrent-operations/

With

context-parameters

(2.2.0-Beta2) is it expected to be ambiguous in the call to

helloContext

when nested inside two applicable scopes? I would have expected it to resolve the same way as the receiver case (that is, with the closest applicable candidate taking priority, given you can disambiguate to the outer scope explicitly with a

with(this@outer)

or

context(this@outer)

) (snippet in thread - slack went weird and thought it was a binary)

Any chance context parameters can be made to work with

@RestrictsSuspension

? I want to do something like:

context(s: SequenceScope<Int>)
suspend fun Int.yield() = s.yield(this)

but it errors.

Are there any plans to add module import declarations to Kotlin similar to Java 23? https://openjdk.org/jeps/476 It would be very useful to import an entire module along with all of its declarations. The need is definitely there currently, as for example Ktor literally has an IDE plugin auto-importing the relevant classes to make using it easier. It would be better to just import the entire module instead, which would work for not only Ktor but also any other APIs designed by other developers.

Out of genuine curiosity, what is taking so long for this feature to be available? I feel like I've been waiting for years for it now. Is there a place I can track its progress?

Felt relevant to crosspost here! I'm hoping this starts a conversation about smarter handling of existential (star-projected) types by the compiler frontend. It currently gives up in the simplest of examples, but clearly there's some handling logic in the compiler. Hopefully, type inference can support existential types better in the future!

To clarify, based on both the Rich Errors talk, and the Outference talk: The initial prototype for rich errors will not support generic errors. However, generic errors are planned, and are part of the intended design, but they have to wait on the outference getting implemented. Is that all correct? If so, I'm very excited because watching the Rich Errors talk, I was quite worried about the amount of limitations on them, but if those limitations are only in the initial prototype, then phew!

Related to the Rich Errors proposal, will it be possible to combine errors generically? That is,

error object First
error object Second

val a: Int|First = TODO()
val b: Int|First|Second = foo(a)

fun <E : Error> foo(e: Int|E): Int|E|Second // ?

Will this be legal?

About this https://kotlinlang.slack.com/archives/CQ3GFJTU1/p1743305751162529 (support for variadic generics). Would we have any timeline / experiment done around it?

I've been playing around with

@RestrictsSuspension

a bit, and I'm coming to the conclusion that it effectively implements resource/capability tracking, but restricted to 1 type, and while also interacting with suspend and the generated code in the obvious ways. I wonder if its implementation could be generalized to a frontend-only, multiple capability implementation, especially with context parameters

Context parameters are arriving in experimental mode in 2.2. Is there a binary compatibility guarantee from 2.2 to the future, even if the syntax and limitations are still subject to change (like for contracts)?

Is there an issue for default types for generic type parameters? And, has this ever been considered as a language enhancement?

fun foo(range: ClosedRange<*>) {}
fun foo(range: OpenEndRange<*>) {}

foo(5..12)

gets

Overload resolution ambiguity between candidates

because

IntRange

is both

ClosedRange

and

OpenEndRange

… It's a shame because the behavior would be exactly the same no matter which one the compiler chose. Is there another solution other than creating a new overload of

foo

for

ByteRange

,

ShortRange

,

IntRange

and

LongRange

, and also all the unsigned ones?

Hey! I’d love to hear your thoughts on the default applicability of annotations. You might’ve heard that we’re planning to slightly adjust how annotations are applied by default. For example, in a class like

Person(@Email val email: String)

, the

@Email

annotation would be applied to both the constructor parameter and the field, while today it only applies to the parameter. This change seems safe and reasonable, and was originally motivated by KT-19289 At the same time, we’ve been considering a more aggressive default: applying annotations to all applicable targets. For instance, in

@Anno var x: String

, the annotation could be applied to the property, backing field, getter, setter parameter, and so on. This is similar to how annotations work for records in Java. Initially, we were cautious about this idea, we thought it might break some frameworks. But based on recent conversations, it seems this concern may not be as serious as we thought. Perhaps we should move toward this broader default after all. So I wonder if you could share your thoughts and any known pitfalls of changing the default. What do you think?

To clarify the new rich errors proposal, is it planned to add new

error data object NotFound

and all

firstOrNotFound

,

firstOfOrNotFound

etc variants? The KEEP mentions how the language will change, but I didn't see anything about the changes to the standard library.

Is there any rough idea of when type outference will be available as a prototype or experimental? I'm wondering how it deals with some complicated examples I have, including existential types.

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)

Hi. I'd like to have a string escape sequence that makes it easier to include astral code points (value greater than 0xFFFF). So I could write e.g.

"\u{1F995}"

instead of

"\uD83E\uDD95"

or

"🦕"

. Granted, often it's preferable to use the last variant. But there are cases where (programming) fonts are missing glyphs or the code point isn't associated with a visible character. In such cases, having to use escapes of the surrogate characters just doesn't make for a great developer experience. Does this sound like something that has a chance of being added to the language? Or would I be wasting my time if I wrote up a KEEP? (I already have a prototype to add support to the compiler.)

Related to KEEPs, there are a couple problems imo with the way Discussions are handled by GitHub. • GitHub displays Issues on the dashboard's Recent Activity, which means they're immediately visible (I don't forget about them) and I can see when they've been updated as they raise up to the top. • GitHub doesn't display the count of open Discussions, and it may look like there are none to someone that's never, or rarely, used them. On the other hand what I like about Discussions is I can order by most upvoted thread. Tho, I don't like that thread upvotes are separated from reactions.

With Rich Errors, will we have a well-typed

suspendCoroutineUninterceptedOrReturn

and

startCoroutineUninterceptedOrReturn

? That'd require making

COROUTINE_SUSPENDED

an Error type, which is hard since it's currently an

enum

member for serialisation's sake. I imagine, because this is an intrinsic, it doesn't matter much

Off topic but Java has a nice history page on wikipedia https://en.wikipedia.org/wiki/Java_version_history is there something similar for kotlin ?

Is there a YouTrack issue or similar thing I can upvote for the

local

parameters mentioned in the outference talk? I was not able to find any myself

Any plans for intersection types? My understanding is that the type system already uses them, no? Are there some rough edges that need to be improved before they can be made denotable? There's a few tricks btw to get them to show up, mostly involving using

InlineOnly

.

Will Kotlin support some form of structural typing on top of its nominal typing? I recently did a lot of Typescript programming, and found its structural typing very versatile and suitable for data-intensive business applications.

Hi 👋 I have a question regarding rich errors that are expected to be introduced in Kotlin 2.4. Many libraries we use—whether Java-based or Kotlin libraries that don't adopt this feature—still throw exceptions. In those cases, we either need to use runCachingAsError to convert them into a general error class, or manually wrap each exception from those libraries ourselves. Is there any plugin currently in development that can automatically generate Error classes, Error objects, or even type aliases from existing exceptions? Since Java relies on exception inheritance, it would be great to have a way to map that structure to Kotlin's error model.

Hi! I was wondering how other people handle sharing internal code across modules without leaking it to the public API. I'm currently working on a Gradle plugin, and I have constants that are shared between multiple modules but I'd rather not have exposed to the end user. I wish there was a way to have something akin to the

internal

modifier but with the possibility to scope to multiple modules. I figure it's probably a niche request so I was wondering how other people have handled the situation.