Is there any way we can say that a companion object shouldn't be used directly? For example,

String

has a companion object whose only purpose is to allow extension functions, but unfortunately I've seen people who are beginners in Kotlin writing code like

val x = foo()?: String

- presumably thinking

String

is the empty string, and not realising that it's the companion object. I can't think of any syntax that would allow us to mark such objects as not allowable to be used in this way.

Can we get rid of the

override

keyword? Do we really need it?

Not sure this is the right channel, but what would need to happen for sumOf to be able to work on anything with a plus operator?

Reproposing this just in case it's been lost to the sands of time: without this kind of thing it's hard to make an "idiomatic kotlin" redis map wrapper for example. https://youtrack.jetbrains.com/issue/KT-20424

Regarding KMM direct interoperability with swift. I've read the recent update stating it's on hold due to limited resources. Does this usually means it will just happen later or it will be probably dropped? Was really hoping for this one :-) https://youtrack.jetbrains.com/issue/KT-49521

I have a use case for inferring nested generic types in a function's definition. Consider the following code:

interface Input<T>  { ... }
interface Output<T> { ... }
fun <In: Input<T>, T> registerForOutput(): Output<T> { ... }

Based on the type of

In

, I want to be able to use

registerForOutput

to create an

Output

instance of the same generic type. In this situation, I refer to

T

as the "nested generic type of `In`" in the context of

registerForOutput

. To re-word the initial sentence: I want

registerForOutput

to return an

Output

with the nested generic type of

In

. Consider the following code:

class ConcreteInput : Input<String> { ... }
val output = registerForOutput<ConcreteInput, String>()

The code above provides a developer experience that is not ideal. A developer, despite knowing that

ConcreteInput

uses

String

as the generic type for its implementation of

Input

, still needs to explicitly define

String

as a secondary generic type of the call to

registerForOutput

. This is only a minor inconvenience in the case that

Input

has a single generic type, but in the case that

Input

has two, three, or even more generic types, this becomes significantly less enjoyable to work with. I believe that this could be improved by including an "inferred" keyword, which is usable within generic type definitions. Consider the following code:

fun <In: Input<inferred T>> registerForOutput(): Output<T> { ... }

In the code above, we state that

T

, the generic type of the generic

In

(the "nested generic" of

In

) should be inferred by the compiler, meaning that it would be possible to write the following code, where the type out

output

should be `Output<String>`:

val output = registerForOutput<ConcreteInput>()

The following code should infer that the

T

of

registerForOutput

is

Int

, and the type of

output

should be `Output<Int>`:

val output = registerForOutput<Input<Int>>()

The following code should infer that the

T

of

registerForOutput

is

Nothing

, and the type of

output

should be `Output<Nothing>`:

val output = registerForOutput<Input<*>>()

Ideally, the

inferred

keyword that I am suggesting should be compatible with

reified

, so that it's possible to write the following:

inline fun <In: Input<inferred reified T> registerForOutput(): Output<T> {
    println(T::class.java.simpleName)
    ...
}

I am interested to hear feedback on whether or not this makes sense (or is possible) as a language feature!

nested destructuring declarations?

Hi all, I don't know if this is the right channel, but I encountered the function

toDoubleOrNull()

(similar functions exist for other numeric types). This extension function is defined on

String

instead of

String?

Would it make sense to define this function on

String?

instead so a null-valued String just returns null? I noticed that

toBoolean()

is defined on

String?

as well.

There should be a

inline fun <T> T?.println(): T? {
    println(this)
    return this
}

so I dont have to move my caret around when trying to debug

Hello, currently, when you have

private val useMe

that you access in

public fun callMe(…)

, if you want to make

callMe

inline

, you are forced to change

useMe

visibility to

internal

and add the

@PublishedApi

, which has the unintended effect of letting

useMe

be accessed outside the file where it resides along with

callMe

. I don't like to leave that door open as the intention is poorly communicated IMHO. Here's my proposal: allow

@PublishedApi

to target

private

symbols. The API would still be published, and tools like kotlinx api validator would need to take it into account, but it'd avoid exposing something in a module where it's only intended to be used in a file. What do you think?

When using a

Result

it's often useful to map an exception to another type of exception, has there any thought been given to adding something like

mapFailure

to the

Result

i.e.:

inline fun <R> Result<R>.mapFailure(transform: (exception: Throwable) -> Throwable): Result<R> {
    return when {
        isFailure -> Result.failure(transform(exceptionOrNull()!!))
        else -> this
    }
}

Usage:

Result
    .failure<String>(NullPointerException())
    .mapFailure {
        MyDomainException()
    }

automatic parameter assignment with matching variable name. Imagine you have

class Entity(val fields: Fields = ..,
             val inner: Inner = ..,
             val owner: Owner? = null)

right now if I want to pass

owner

, I have to use named parameters

Entity(owner = owner)

, which is redundant if the variable naming matches, imho

Will it be possible to pass function references to functions using context receivers in the future? E.g.

context(MyContext)
fun sayHello(name: String) {
  println("Hello $name")
}

fun main() {
  with(context) {
    listOf("a", "b").forEach(::sayHello)
  }
}

Right now it gives an error because sayHello is a

KFunction2<MyContext, String,Unit>

when a

(TypeVariable(T)) -> Unit

was expected.

I've mentioned this on the forum before, but it didn't seem to get any response, what about a syntactic sugar, which allows you to declare one method which can accept multiple types, which just gets desugared into multiple methods? For example:

fun timesTwo(num: Double[(s: String)->s.toDouble(), (n: Number)->n.toDouble()]) = num * 2

Which can be separated into two methods by the compiler, and this would get rid of conversion methods, which would reduce redundancy? Though admittedly the syntax I designed for it is pretty bad, but I trust you guys can do better than I can :D.

This message was deleted.

It should be possible to specify a default value for type parameters, is there any issue opened about this?

📣 Some time ago we have conducted a UX research that showed that Kotlin users may experience troubles identifying whether the ranges created with the

..

operator and

until

function have their upper bound excluded or included. Now we present the proposal intended to improve this situation by introducing the new

..<

(rangeUntil) operator to Kotlin. Please use KEEP-314 for the discussion.

This code prints "0" on JVM and "undefined" on js. In this example it's obvious that I'm forcing something the compiler doesn't like (without the lambda, it will correctly complain that foo is not initialized) but in my actual use case it was not obvious and took a lot of time to track down why js behavior was different than jvm. Is there anything the compiler can do to help with this, the way it does with lateinit?

import kotlin.test.Test

class Undefined {
    init {
        println({ -> foo }.invoke())
    }

    val foo = 0
}

class Foo {
    @Test
    fun testUndefined() {
        Undefined()
    }
}

A small proposal, currently on Kotlin Multiplatform if someone wants to define inline classes one has to use @JvmInline annotation on jvm sourcesets and not use it on non-jvm sourcesets which creates an unnecessary platform sourceset split since the code could otherwise be platform agnostic. Since it is an annotation to indicate to the JVM backend to use a specific opitimazation other targets (Kotlin/JS and Kotlin/Native) could just ignore it without throwing an error. (Treat it as a no-op on non-jvm backends) Filed on YouTrack: https://youtrack.jetbrains.com/issue/KT-53404/Treat-JvmInline-annotations-as-no-op-on-non-jvm-backends-for-better-Multiplatform-experience Example on playground: https://pl.kotl.in/R4XMcQfCJ

// ^ Try different backends
// v And commenting out or not
// @JvmInline
value class NonEmptyString(val value: String) {
    init {
        require(value.isNotEmpty())
    }
}

fun main() {
    println(NonEmptyString("Hello"))
    try {
        println(NonEmptyString(""))
    } catch(e: Throwable) {
        println("Woops!")
    }
}

I would like to propose a feature: lambda as extension function. My use case: in Android, Timber records the class that requested a log event along with the log. I have a few wrappers of this that I put in my util class, for example.

fun <T> ld(t: T, getMessage: (T) -> String) = Timber.d(getMessage(t))

and

fun <T> T.ld() = this.also { Timber

.

d(it) }

The issue is that the class is always the util class. Writing

val

`ld = {(

insert previous code)

}` works for the former wrapper, but not the latter. I use the latery for chaining.

Suggestion: allow omitting the receiver type from a callable reference when it can be inferred from the expected type.

data class A(val name: String)

fun <B> A.getProp(prop: A.() -> B) = prop(this)

fun A.getName() = getProp(::name) // I want this

fun A.getName2() = getProp(A::name) // But I have to do this instead

A special method:

operator fun usedAs(): SomeType

When the code is compiled, this method is automatically called if it's used as a parameter in that type. That might be a bit confusing, let me elaborate.

operator fun String.usedAs(): URL = URL(this)

And then the user can use String in place of URL in method call and constructors. Then the compiler can desugar it to the method call. Though since now you can't really have two methods with the same name, I would make it something more like

@Converter(URL::class)
fun asURL(): URL = //...

Make operator methods annotation based instead of name based, as to allow customizable naming of methods, perhaps someone would like their

*

to call

multiply

instead of

times

, and

operator fun times(other: A) = multiply(other)

is just more boilerplate. Something like

@Operator(TIMES)
fun multiply(other: A) {
    //...
}

would be cool :D.

So I've seen there is some xml based option to declare external annotations for IDE, but I was surprised I have not found this to be an official thing. I'm still not sure how it works already so I'll ask here first - how about embedding such mechanism into core language? I.e. to be able to 'add' annotations for declarations from external modules that are then considered by the compiler when compiling this module. Use cases: • `@Nullable`/ `@NonNull`for java declarations. • `@Stable`/ `@Immutable`for Jetpack Compose - see this thread • `@Deprecated`for when you want to prevent using some symbol from external library Of course not all annotations would make sense to be used that way (think

@Volatile

) so there could be a meta annotation `@External`that only enables that annotations to be used externally.

based on a post of mine in "getting-started" https://kotlinlang.slack.com/archives/C0B8MA7FA/p1659464960124589 currently its possible to define an inner function within builders. If you have recursive logic, this is nice to work with. e.g. for a personal project I can easily do this:

fun holeFiller(spaces: Int, totalSum: Int): List<List<Int>> = buildList {
    fun fill(sumToGo: Int, list: List<Int> = emptyList()) {
        when (list.size) {
            spaces - 1 -> add(list + sumToGo)
            else -> for (i in 0..sumToGo) {
                fill(sumToGo - i, list + i)
            }
        }
    }
    fill(totalSum)
}

However, if I want to have this with a sequence, the function "fill" needs to be specified as

suspend fun SequenceScope<List<Int>>.fill

It would be nice if an inner function of a sequence implicitly works like this

It would be great to have union types just for external declarations in K/JS, so it's a lot easier to create typings for a TypeScript library. I think it would be a pretty easy task to implement it just in that specific context so this is why I post a message specifically for this

I have a function that takes two numbers and does simple arithmetic on them. Why do I have to write the same function twice if I want to pass in an

Int

or a

Long

? Either that, or convert the parameters to the expected type every time. A solution could be including the arithmetic operations in

Number

, besides for the conversions.

I've been thinking of a practical way to

return

a certain value based on a condition, and I'd like to propose this feature:

return x if != null
// <and/or>
return x if user != null

Same for

break

or

continue

Other examples:

return x if >= 5
return x if is User
return x if x + 1 >= 5

And maybe:

x = 5 if x < 2

Is there any reason that Kotlin allows for inner classes, but not inner objects?

Why is the

const

keyword necessary? I understand that

const val

is for compile-time constants and leads to different (presumably better) code than

val

, but why couldn't the compiler generate the better code if a [static]

val

is assigned a compile-time constant? In other words, why does the compiler generate different code for these two lines?

const val PI = 3.1415
val PI = 3.1415