A transitional annotation for changing a DSL from passing receivers to passing contexts may be really nice to have. @Alejandro Serrano.Mena ran into this issue where using

context

consistently, even for DSL builders that pass a single context, is superior for a nice experience. Maybe this annotation makes a receiver only appear as a context for users that have contexts enabled, thus preparing for when everyone has them enabled to then "flip the switch". It can then also warn users who refer to

this

explicitly for an annotated receiver and recommend changing to

contextOf

instead. Perhaps a similar thing can also be applied to methods that take in an extension receiver now but want to take a context in the future, but that feels less useful for DSLs you can simple

@Deprecate

the extension version and introduce the context version right away, but you can't do the same with block DSLs

I'm currently migrating a codebase that used a lot of dollars in string literals to using multi-string literals, and while the language feature itself is great, the tooling support… could be improved. Let's take this snippet:

val foo = "\$foo"   // Warning: add interpolation prefix
println("""
	foo: $foo
""".trimIndent())

Let's follow the warning. We get:

val foo = $$"$foo"
println("""
	foo: $foo
""".trimIndent())

So far, so good. But now, the variable is pointless. Let's inline it, we get:

println("""
	foo: $foo       // doesn't compile
""".trimIndent())

Sometimes, it does actually inline it into:

println("""
	foo: ${$$"$foo"}
""".trimIndent())

which was probably not the intent behind the KEEP. There is no inspection there to add an interpolation prefix. There is also no inspection for:

println("""
    foo: ${"\$foo"}
""".trimIndent())

Code highlighting frequently gets it wrong (e.g. see attached screenshot). In the end, I'm pretty much did the entire migration manually. Especially now that the team is proposing changing existing syntax in every other KEEP, I'm worried that tooling is being left off as an afterthought.

Would

MultipleChoices

not qualify for context sensitive resolution here? It's a list of sealed class (from KOOG)

regarding rich errors: looking at the code it seems like at least ?. syntax will not be able to distinguish between a null and an error; is that intended?

Hey guys 👋 I'm sorry if I'm not in the right channel, I didn't find a better one, but I think it's related enough. I'm trying context parameters, but failing in this case:

fun bar(
    lambda: context(String) () -> Unit
) {
    with("") {
        lambda()
    }
}

fun foo() {
    bar {
        this // error
    }
}

Am I missing something? Is this not supposed to give me a string? I am not able to get the context parameter of the lambda in any way. If I try

bar { str ->

then "str" here is also an error 🤔

https://github.com/Kotlin/KEEP/issues/445 has been created as an issue but the other recent KEEPs were created as discussions, was there a change in policy?

Why are non-tail-recursive functions marked with

tailrec

only a warning and not an error?

Very interesting JVMLS talk on "typeclasses" in Java: . If it does make it into the language it's likely to come into Kotlin in some form for interop, and it's also something that Kotlin can't really do at the moment.

Context sensitive resolution: why doesn’t it work for classes in sealed hierarchies?

Does JB state anywhere the recommended code style for enums? I see many projects including JB are moving to CamelCase over SNAKE_CASE

Is there a way to mark a class constructor as private-in-file? Currently I have to use

internal

to get the closest behavior but I really would want it to only be accessible in-file. If not, would be very nice to have.

Just came here to say that I hit my first natural use case for context parameters, and I love it!

Has anyone made a

@Bridged

KSP plugin yet that generates contextual bridge functions?

Is that possible to add literal types (like what typescript has) to Kotlin? and add a limited version of union type (like what is introduced for Rich Error feature) for literal types? So make some really fun and helpful things possible:

fun rollDice(): 1 | 2 | 3 | 4 | 5 | 6 {...}

or

fun switch(switch : "on" | "off") { ... }

I understand why for

getValue

and

setValue

the semantics of context-parameters would be murky (is the context resolved on use or on declaration), but what is the reason not to support context-parameters on

provideDelegate

? Would the semantics not be quite clear that the context-parameter is used at declaration, i.e at the

val x by y

and non-contextual

getValue

/`setValue` used as any other delegate?

Is there any chance

org.jetbrains.kotlin.plugin.assignment

becomes integrated with the core language at some point? It's a nifty feature that I'd love to use in my own DSLs.

I vaguely remember an announcement about forcing named parameters, but I don't remember where I saw that, and I can't find anything about it. Did I hallucinate it 😅

What's the reason behind not supporting passing parameters by name to java functions? It is mentioned in the docs [here](https://kotlinlang.org/docs/functions.html#unit-returning-functions):

When calling Java functions on the JVM, you can't use the named argument syntax because Java bytecode does not always preserve the names of function parameters.

However, nearly all java code these days is compiled with the metadata needed; and any changes (in either dependencies or combined-source java files) would be no more breaking than with kotlin. Given that stability, and by-name parameters mechanics being relevant only at compile-time, I'm not sure why the regular java metadata can't be used?

When can I use the

implicit

function for context parameters? I am experimenting and I can find of no other way to access the context inside of an context inside a lambda. EDIT: it appears to be https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/context-of.html

At this stage (2.2.20), what is the expected stability of context parameters? I don't see much activity in the KEEP. It seems to me that we're at the stage of "they seem mostly done except maybe a few implementation bugs, they will probably be stable in 2.3 or 2.4 but without any major API or ABI changes". Is this correct? I have a few pre-stable libraries that would benefit from context parameters, so if that's the expected timeframe & risks, I'm willing to risk it.

So do I understand correctly that lambdas no longer have implicit access to context parameters at all? The KEEP and some other places still reference this as an option fairly recently. When was that removed? I must be missing some discussion

I have a remark about context parameters. I am experimenting with them and it solves quite a few DSL problems, but I also notice that it heavily reduces 'code discoverability' in autocomplete from IntelliJ. What do I mean with this? When you have "regular" code with some dependencies like follows:

fun doFoo(depA: DependencyA, depB: DependencyB, param: Param) { ... }

you can type

doF

in IntelliJ and see the possible options that are available in this scope. However, when you have context parameters you have the above example as follows:

context(depA: DependencyA, depB: DependencyB)
fun doFoo(param: Param) { ... }

you will never get

doFoo

as suggestion if you do not have proper contextual scope. This makes perfect sense of course! However, it greatly reduces ways to discover API's via IntelliJ, without going fully into docs / source code. I can imagine that working with foreign API's which require context parameters it is hard to find the proper functions. Are there any ideas around this? E.g, autocomplete/hinting with suggestions that will work if you add more context?

The interaction between

reified

and interface methods is unfortunate. Let's say I have:

interface Container<T> {
    fun <O> map(…): Container<O>
}

But, I want to know the type of the contents of the container (because of KotlinX.Serialization, because type parameters are erased).

interface Container<T> {
    val type: KType
    fun <O> map(type: KType, …): Container<0>
}

That works, but specifying the

type

is not convenient, so I'd like to have a convenience overload:

interface Container<T> {
    val type: KType
    fun <O> map(type: KType, …): Container<O>
    inline fun <reified O> map(…): Container<O> =
        map(typeOf<O>(), …)
}

but

inline

can't be used within interfaces, so

interface Container<T> {
    val type: KType
    fun <O> map(type: KType, …): Container<O>
}

inline fun <T, reified O> Container<T>.map(…): Container<O> =
    map(typeOf<O>(), …)

This actually decreases developer experience quite a bit because IntelliJ will always auto-complete the inconvenient overload much higher than the convenient one. Also, I can't make the initial

.map

function

protected

, so I have to use opt-in annotations. But let's say that I have an implementation

class Foo<T> {
    override fun <O> map(…): Foo<O>
}

Notice how it returns an instance of itself to users. Now that

.map

has become an extension function, it's not possible anymore to override it to change its output type. Also, it's not possible to have a

Container<Nothing>

anymore because

reified

forbids

Nothing

.

Higher-kinded types could be cool to have. To be honest, I haven't felt a need for them that often, but it feels like a simple enough feature to add. Ideally, it should play well with typealiases too, so we don't have to do the gymnastics that Haskell does. A simple use-case is a Functor type-class (to be used with context params):

interface Functor<F<_>> { // Imaginary syntax, based on Scala's F[_]
  fun <A, B> F<A>.map(f: (A) -> B): F<B>
}

object ListFunctor: Functor<List> {
  override fun <A, B> List<A>.map(f: (A) -> B): List<B> = ...
}

It's good to note that Kotlin doesn't have raw types, unlike Java, and so seeing just

List

means the type constructor

List

, and not a raw type equivalent to

List<*>

I've been using context parameters a lot, and one thing I really miss is the ability to pass

KFunctions

in places where lambdas with context are expected. For example

class Server

data class Foo(val action: context(Server) (Int) -> Unit)

context(_: Server)
fun doSomething(int: Int) { ... }

// val foo = Foo(::doSomething) This currently doesn't work
val foo = Foo { doSomething(it) }

I would really like to be able to pass

::doSomething

into

Foo,

but it doesn't work currently. I know context parameters are experimental, is this something expected to be fixed/added in the future? There's a YouTrack issue for this, but I don't see any timeline for it or if it's even expected to change.

Are there ideas about extension interface implementations? At the moment we can create extension functions, but I would find it very interesting if it would be possible to implement an interface by extension. Basically it would boil down to traits. I like the idea of adding behavior to data structures you do not own.

Kotlin have

internal

modifier that it is module wide. Why not to make

sealed

classes also module wide? I have lot of cases in my code where declaration of base class is in somePackage and all inherited classes in somePackage.subPackage. Now it is not possible to use sealed classes such way.

There are times (mostly when needing to import multiple types with clashing names) that I'd like to take the golang approach of importing (potentially with an alias) an entire package and using qualified references. This can kinda be simulated with

-Xnested-type-aliases

by declaring an otherwise empty

object

containing only type aliases for the types you want to 'export'.

Start using context parameters. Noticed that sometime there is a need to make all functions in class/file define within the same context. It will be very nice to have posdibility to define context parameters on class or file, to not repeatedly do it for each function.

w: Language version 1.8 is deprecated and its support will be removed in a future version of Kotlin

Looks like this is already on the table. What's the plan for moving off of 1.8 as the minimum supported version?