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

The KEEP proposal for "Named-only parameters" feature is open for public review

I think I may have already seen this suggestion at one point, but I could make my multiplatform libraries lighter weight with it - I need a

type

.

// expect files only

expect type ViewNode

expect type TextInput: ViewNode

expect val TextInput.content: String

// actual files only

actual typealias ViewNode = HTMLElement  // js

actual typealias ViewNode = View  // android

actual typealias ViewNode = UIView  // ios

actual typealias TextInput = HTMLInputElement  // js

actual typealias TextInput = EditText  // android

actual typealias TextInput = UITextField  // ios

actual fun TextInput.content get() = this.value  // js

actual fun TextInput.content get() = this.text  // android

actual fun TextInput.content get() = this.text  // ios

type

would have no restrictions about what the actual is - it could be a

class

,

interface

,

open class

, or more. Consequently, you wouldn't be able to use the type for anything other than an input, output, or receiver to a function.

Alternative proposal to the above based on @Chris Lee’s point:

expect value class ViewNode
actual value class ViewNode(val android: View)  // android
actual value class ViewNode(val web: HTMLElement)  // web
actual value class ViewNode(val ios: UIView)  // ios

To be clear, this doesn't currently work, but it would be nice if it did.

I’m trying out the new Context Parameters feature. They can be used on properties, but seems the context applies to both the getter and setter. Would it make sense to be able to specify different context for getter and setter? For example, I have

Preferences

and

MutablePreferences

, and the context for

get()

should be

Preferences

, and the context for

set(value)

should be

MutablePreferences

Context parameter defaults?

context(clock: Clock = Clock.System) fun functionRequiringTime() = TODO()

I could see myself using this to make the common use cases straightforward while still handling tests correctly.

Is there a way in Kotlin to get all arguments of a function as a Map<String, Any?>, where the keys are the names of the arguments? If not would this be proposal worthy?

I want to draw attention to an idea of chained `when`’s by @Wout Werkman:

val m = list.min().when { NoSuchElement -> 0 }

someExpression.when { 
  it < 0   -> Int.MIN_VALUE
  it > 100 -> Int.MAX_VALUE
}.doOtherStuff()

Default else branch is obviously

else -> it

. We propose only allowing the anonymous parameter `it`; if you need to name it, use the ordinary when. Chained `when`’s seem to be the perfect fit for rich errors where the elvis operator

:?

is no longer, but have great applications otherwise.

Over the course of the last few years, I have prepared a package of far-reaching language design proposals significantly improving expressiveness and reducing boilerplate. The list includes in particular • Painless type providers, • First-class logic programming, • Effortless dependency injection As opposed to small incremental improvements, such ideas will only go into development if a significant number of users are eager to have them. Please take a look at https://akuklev.github.io/kotlin/, discuss and share if you would like to see some of these features in Kotlin.

Overloadable question

?

and elvis

?:

operators? This is already kinda part of the rich error proposal, but it only works for error unions there, but could also just be useful on its own. It's essentially just syntax sugar for a monad

map

. Basic example (not sold on this syntax):

sealed interface ParseResult<T> {
   data class Success(val value: T) : ParseResult<T>
   data class FormatError(val expected: String, val got: String) : ParseResult<Nothing>
   data class Failure(val cause: Exception) : ParseResult<Nothing>

   operator fun <R> question(operation: T.() -> R): ParseResult<R> =
      if (this is Success) this.value.operation() else this
   
   operator fun <R : T> elvis(operation: () -> R): T = 
      when (this) {
         Success -> this.value
         else -> operation()
      }  
}

fun Foo.Companion.parse(str: String): ParseResult<Foo> = //...

fun example() {
    val foo: Foo = Foo.parse("hello world")?.doSomething() ?: Foo.None
}

I don't really like how the elvis overload works here, but I think it gets the idea across.

The first KEEP on rich errors is now open for public review: https://github.com/Kotlin/KEEP/discussions/447 It mainly covers our motivation behind the feature but also outlines the core design rules

I've been working a lot with context-parameters, and they're pretty fantastic overall, but I am running into a lot of repetition. For my use case I have one context that I'm passing around to a lot of functions, and I don't really like having to type

context(...: Foo)

over and over again. What if you could create context-aliases that look like keywords? I.e.

interface ServerContext

contextalias server = context(serverContext: ServerContext)

server fun foo() { ... } // same as context(_: ServerContext) fun foo()

This one is a bit of a long-shot, and I would be open to alternatives, but something like this would be nice.

We've just published a document with details on the new data flow-based exhaustiveness checker to come as experimental in 2.2.20. This is a feature designed to stay out of your way -- in fact, it should help getting rid of useless

else

branches.

Besides the data flow-based exhaustiveness checker proposal, today we also publish the "`CoroutineContext` context parameter in

suspend

functions" exploration proposal. Text Discussion

A KEEP to improve compile-time constants is now open for public review. The changes are designed to fix some inconsistencies in the language and aims to unify behavior across different types and within the standard library.

👋 Hi ! Have you ever been in a situation where you have to write a function which create an instance from a class?

fun <T> buildInstance(clazz: Class<T>): T

… but this works only with classes which declare a constructor with a specific signature signature? In such cases, constructor declaration in interfaces (or something similar) would help to keep code robust at runtime, right?

interface Buildable {
    constructor(param: Sting)
}

fun <T: Buildable> buildInstance(clazz: Class<T>): T {
    return clazz.constructor("param")
}

What do you think about this idea 💡?

We’ve published Refinement Types Design Notes - a research on expressing more precise constraints on values with refinement types. It’s not a proposal, but we’d love to hear what you think. Design Notes Discussion

For the Kotlin code:

for (i in 0 until 5) {
        println(i)
    }

this compiles into Java:

for(int i = 0; i < 5; ++i) {
         System.out.println(i);
      }

However, revising it to:

(0 until 5).forEach { i ->
        println(i)
    }

turns it into the vastly less efficient:

Iterable $this$forEach$iv = (Iterable)RangesKt.until(0, 5);
      int $i$f$forEach = 0;
      Iterator var2 = $this$forEach$iv.iterator();

      while(var2.hasNext()) {
         int element$iv = ((IntIterator)var2).nextInt();
         int var5 = 0;
         System.out.println(element$iv);
      }

Could the compiler be optimized to recognize when it is creating an

Iterator

from a well-known

Range

, whether that's for

forEach

,

forEachIndexed

,

all

, etc., and use the more efficient for-loop instead? Adjusting the above code to use the first form instead of the second form is trivial enough, but optimizing a call like:

(0 until 10).all { evaluatesCorrectly(it) }

ends up looking something like:

run {
        for (i in 0 until 10) {
            if (!evaluatesCorrectly(i))
                return@run false
        }
        true
    }

which is more efficient, but not nearly as concise.

A new KEEP introducing explicit context arguments for context parameters is out! Any feedback can be given in the corresponding discussion

Generic copy for generic data classes. If I have a generic data class:

data class Basket<Fruit>(fruit: Set<Fruit>)

And an instance of it:

val bananas : Basket<Banana>

The type checker does not allow:

val apples : Basket<Apple> = bananas.copy(fruit = listOf(apple1, apple2))

Instead, I have to call the constructor of new Basket<Apple> explicitly and copy fields from the Basket<Banana>. What do people think about making the copy method generic for generic data classes?