Hi folks, a general question: is there any doc about why the kotlin-team decided to make kotlin classes by default final? Im looking something like a KEEP. I searched in the Keep, docs, and now im looking in the spec but i cant find any detailed explanation like in the keeps. Does anyone know if it even exists something similar? Thanks in advance for any answer 🙂

Does anyone know why the new underscore type operator in Kotlin 1.7 seems to not be working for me? I'm using the Android Kotlin gradle plugin with Kotlin 1.7, and wherever I put "_" for a type argument, I just get "Unresolved reference: _". Is this a feature that needs to be explicitly opted-in to? From the 1.7 feature update it sounded like this should work be default. Even a simple example like mapOf<Int, _>(2 to 3) doesn't work for me.

// in kotlin you can
suspend fun hi() {
    suspend fun thing() {
    }
 
    thing()
}

// you can
suspend fun hi() {
    val thing: suspend () -> Unit = {
    }

    thing()
}

// you can
fun hi() {
    val thing = fun() {
    }
  
    thing()
}

// but you CAN'T
suspend fun hi() {
    val thing = suspend fun() {
    }

    thing()
}

any specific reason?

Does Kotlin 1.7.10 is out ? There is this on the website :

Does

@OverloadResolutionByLambdaReturnType

not cover the case where one of the return types is a subtype of the other? For instance, this surprisingly fails (playground):

@OptIn(kotlin.experimental.ExperimentalTypeInference::class)
@OverloadResolutionByLambdaReturnType 
inline fun printIf(condition: Boolean, message: () -> Any?) { 
    if(condition) println(message()) 
}
inline fun printIf(condition: Boolean, message: () -> Int) { 
    if(condition) println(message()) 
}
fun main() {
    printIf(true) { 42 }
    printIf(false) { "hello world" } // Type mismatch: inferred type is String but Int was expected
}

This can obv be used to avoid boxing primitives like Int when unneeded. I know the cost of boxing is marginal, but in a tight loop it can be detrimental.

The idea of compiler plugins has been floating around for a while now, and 1.7.0 has started to make some strides in that direction. Is the plan for compiler plugins to eventually work similarly to Rust's macros? Effectively allowing the kotlin community to build their own kotlin features and syntax? Or am I thinking about this incorrectly?

why is it applied to tests?

This case is not considered exhaustive and results in compilation error:

when (Pair(bool1, bool2) {
    Pair(false, false) -> {...}
    Pair(false, true) -> {...}
    Pair(true, false) -> {...}
    Pair(true, true) -> {...}
}

Is it just because it's too difficult for the compiler to figure out that it is in fact exhaustive?

Any idea why

then

is an infix function but

thenBy

isn't?

What about adding a contract to delegated properties, which allows smartcast with the provided value by ensuring to always provide the same value? Use case: kotlinx-cli parser or Compose State. Both libraries ensure the provided value is stable and does not change.

val parser = ArgParser("ejwrapper")
val jobID by parser.option(ArgType.String)
parser.parse(args) // No changes to jobID after parsing

if (jobID != null) {
    val status = getJobStatus(jobID) // smart cast is not possible because jobID has a open or custom getter

Current workaround is

!!

, another variable or

let

so no changing the type of a member with copy()? is there an issue i can go vote? 🙂

Wouldn't it be cool (not necessarily simple to implement) to be able to specify the constraints of a function's input and have them checked statically and guaranteed by the compiler, just like it does for null safety? For example, that a number is within a certain range (more so than the fact that the number fits into a Short or Long), or a string isn't empty or matches a regex. Possibly more complex things would be that a list can't be empty, or that the parameters match certain predicates. In some ways this is the logical next step in specifying the constraint that objects can't be null (specifying other constraints). I feel like function bodies would be more focused on what they are actually meant to do, instead of verifying input validity. In some ways this is basically a

contract

about the preconditions. There could even be an error message associated with each precondition.

@Precondition(
    target=a,
    condition=Preconditions.nonNegative(), 
    message="a cannot be negative!"
)
@Precondition(
    target=a,     condition=Preconditions.lessThan(b), 
    message="a must be less than b!"
)
fun foo(a: Int, b: Int)

Could also apply to variables:

@Invariant(condition=Preconditions.nonNegative())
@Invariant(condition=Preconditions.inRange(1..5)
var x: Int

Could possibly do

@Invariant(conditions=[...])

Why is this syntax for multiple context receivers:

context(Logging, Application)
fun hello() {
  <http://logger.info|logger.info>("Hello " + applicationName)
}

Prefered over this:

fun (Logging, Application).hello() {
  <http://logger.info|logger.info>("Hello " + applicationName)
}

In my opinion the second one is more readable and makes intuitively more sense when you know how to do one context receiver just put braces around. I'm sure that considerations have been made here, but I can't imagine one real advatage of the first code example over the second one

Is there any plan to improve the exception handling in the nearest future, i.e. enforcing or at least suggesting that there might be exceptions worth handling at compile-time? I know this topic has been discussed multiple times already, I’ve seen a proposal where someone suggested an approach similar to Swift’s, I’ve also seen an apparently still ongoing debate that started as a feature request for checked exceptions but which eventually has evolved to be a discussion on exception handling in Kotlin in general. I’m bringing this up again here because, well, I’m simply not happy with the compiler not warning about exceptions in any way. Don’t get me wrong, I’m not opting for checked exceptions here. I do agree that Java’s way is far from ideal, but I just also happen to think that what Kotlin does right now, allowing any exception to be left unhandled and potentially crash the application, isn’t good either. Especially that it comes from a language whose one of the core features is compile-time null safety which aims to help people avoid crashing their apps partially because of an oversight. And of course, I do understand that it’s a complex issue, many people have different opinions on it, probably some won’t even agree with what I’ve written above, but, regardless of these opinions, exceptions are part of the language and could use better support. Maybe there could be a compiler flag, similar to what we got for the explicit API mode, which would allow developers to tweak the compiler into helping them: • not to forget to annotate their throwing functions with

@Throws

• not to overlook functions annotated with

@Throws

and handle them properly?

Should this be part of the language?

val Any.field
        get() = when (this) { //these classes don't inherit a common ancestor that has the getField() method, so we need to parse them out into distinct classes
            is Class1 -> field
            is Class2 -> field
            is Class3 -> field
            ...
            else -> null? throw error?
        }

A useful feature that would help this case is if I could specify that a function can only be called on certain types, similar to

where

, so that the compiler knows that it is at least one of those classes, and can find the corresponding function or field. At the very least, it would write this out for me.

[Discussion item] Hi, I came across this article Expression problem and its solutions, in this author discusses various languages and how they fall short to solve the expression problem because of lack tools. Author further went and told how Closure though its language features it solves the expression problem A brief explanation on expression problem Imagine that we have a set of data types and a set of operations that act on these types. Sometimes we need to add more operations and make sure they work properly on all types; sometimes we need to add more types and make sure all operations work properly on them. Sometimes, however, we need to add both - and herein lies the problem. Most of the mainstream programming languages don't provide good tools to add both new types and new operations to an existing system without having to change existing code. This is called the "expression problem". Now the crux of the Clojure language to solve the expression problem was open methods i.e you can add methods to the class without changing the source code Here is the Clojure example by author: link After going through this, it occurred to me, the extension functions of kotlin kinda does the almost same job. It allow us to add function to the already existing class without changing its source code in a way (I am excluding the part where in bytecode it creates a static function) Here is my example for kotlin which I think solves the expression problem (gist link)

// Initially I have an interface Expr (just like in Java) and have two classes  (Constant
// and BinaryPlus) implement that interface 


interface Exp {
    fun eval(): Double
}

class Constant(val value:Double): Exp {
    override fun eval(): Double = value
}

class BinaryPlus(val lhs: Exp, val rhs: Exp): Exp {
    override fun eval(): Double {
        return lhs.eval() + rhs.eval()
    }
}


/**
* Here, I added the stringify() method (which is a tool or operation) to the interface Expr,
* without touching the interface and classes which are implementing it.
*/

fun Exp.stringify() : String {
    return when(this) {
        is Constant -> value.toString()
        is BinaryPlus -> "${lhs.stringify()} + ${rhs.stringify()}"
        else -> ""
    }
}

// Here is how, I can use it

fun main() {
    println(BinaryPlus(Constant(4.0), Constant(9.0)).stringify())
}

/**
* Now in object oriented languages, adding types is easier 
* and functional languages adding tools(or operations) is easier 
* but since kotlin can act as functional and object oriented and with my above given example.
* I think extension function solves the expression problem for kotlin.
*/

Is there any information/update on context receivers? The preview was added back in 1.6.20, and there was a flurry of discussion, as well as several issues reported, and I've seen radio silence on that front since. Am I just not following the right sources to get information, or is there indeed no information to be had?

Is there a way I can provide a certain context receiver at the file level?

also, is

context(InternalAddOp<T>, InternalAddOp<R>)

prohibited, cause in theory they could have a subtype relation between them, or is that an error?

I was reading this blog about Dart 3 and their roadmap to sound null safety and found something interesting mentioned about Kotlin:

Kotlin has several unsound exceptions, in part due to its goal to interoperate with Java. As you can see in this Kotlin example, generic types can trigger cases where null values can flow into a list declared as holding non-null elements.

I understand why Java libraries can sometimes be troublesome (

T!

), but I'm a bit confused about the generic types example they're giving, this is the offending code:

private fun <E> List<E>.addAnything(element: E) {
    if (this is MutableList<E>) { this.add(element) }
}

fun main() {
    // A list of non-null Ints.
    var myList : List<Int> = arrayListOf(1, 2, 42)

    // Add a null.
    myList.addAnything(null)
    
    // Add a non-number.
    myList.addAnything("This is not even a number")

    // Print resulting list, not matching `List<Int>`.
    print(myList);
}

Which prints:

[1, 2, 42, null, This is not even a number]

Why is this happening? My first guess is that the

if

in

addAnything

is true because of type-erasure, is this correct?

Hello! Is there any planning to include possibility to pass function argument by ref?

What do you mean by passing function argument by ref?

Is there a reason the only operators allowed in

when (expr) { ... }

blocks are just the four specific operators

is

,

!is

,

in

and

!in

? It seems quite arbitrary to limit the allowed operators instead of saying you can have any binary operator with just its right-hand side (for example,

when (temperature) { < 5.5 -> ... }

Edit: Ignore this. Don't think I can delete this now, but just saw someone else asking the same question above and the answer. Just really surprised I wasn't able to find an answer to this googling. Apologies if this has already been posted, or this is not the right place, but I can't seem to find any information about this online, so I thought I'd ask here. It looks like context receivers were removed from the roadmap. Why? Is this being dropped entirely, or is the focus just on other things right now?

IMPORTANT FEEDBACK Coming from a javascript and python background, I am facing great difficulty in using Kotlin. The same for my friends too. For getting good at Kotlin, the environment is kind of like "You must know java or c++ like language if you want to learn Kotlin". Also, I love using the terminal for most of my work. But Kotlin tries to force you to use IntelliJ. I want to mention that I love the language really and I don't want to leave this language behind. But it has been more than a month or two, and I still cannot figure out how to create an executable using Kotlin. And also, I and sick of using IntelliJ. No offense, but using the IDE for a simple program is not worth it. For this, I don't even feel like writing some coding with Kotlin in my daily life. But I am still not leaving it, as I love the language at its core. So, can anyone help me with this? I can be thinking in the wrong way; in which case guide me in the right direction.

Certainly a long shot but are there any discussions about introducing types that are completely erased (not just generics) in Kotlin? A bit like the typescript type system. At built time, all the type checking would happen. At run time the objects could be some

Map

-like type I guess and property accesses would be cast to the build-time type (and assert if wrong). Does that make any sense?

I can't find a KEEP for it, but I'm guessing people have been requesting

filterKeysIsInstance

and

filterValueIsInstance

on a Map? Would like to track its progress if its there.

Would it be possible/interesting to have the compiler generate the negation of boolean variables and functions that return booleans? For example, let's say this is defined:

val String.isValidUrl: Boolean get() = TODO()
fun areValidCredentials(email: String, password: String): Boolean = TODO()

Then, could the compiler generate:

val String.isNotValidUrl: Boolean inline get() = !isValidUrl
fun areNotValidCredentials(email: String, password: String): Boolean = !areValidCredentials(email, password)

The name could be changed via annotation, or by default the compiler wouldn't do anything but adding an annotation with an optional name could generate the negations..? I feel it would make code more readable than having the

!

before or

.not()

after. The standard library already has some negated function such as List.isNotEmpty, so I feel Kotlin could improve by generalizing this trend.

Should there be a way to make all interface methods optional to implement? Take

android.text.TextWatcher

. I am not interested in

beforeTextChanged()

and

onTextChanged()

, only

afterTextChanged()

. Should the compiler assume (or can I inform it) that I will implement it like this?

object : TextWatcher {
            override fun beforeTextChanged(...) {}
            override fun onTextChanged(...) {}
            override fun afterTextChanged(...) {
                ...
            }
        }