This message was deleted.

I think it would be nice if we could restrict that passing parameters to specific function must use named or positional arguments only. It would make it easier to maintain source compatibility in some cases. I guess it could make it difficult for compiler to preserve binary compatibility for named arguments only functions.

Hey, what do you think about adding some kind of

Int/Double/String/LiteralExpression

feature to Kotlin? Ideally, this would be an interface, maybe even restricted to the compiler only. This would allow you to limit some helper functions to literals only, and don't pollute the namespace with helper methods. Sample

val IntLiteral.seconds: Duration get() = ...

fun getX() = 42
val secs = 2.seconds // valid, as 2 is a constant literal
val secs2 = getX().seconds //invalid, seconds can only be called from a IntLiteral

Swifts similar implementation: https://developer.apple.com/documentation/swift/swift_standard_library/initialization_with_literals

In multiplatform projects, I find it quite inconvenient to have related files split among separate directories where the common parent is multiple levels away. I just got an idea that could resolve this problem: Using the extension to specify the sourceSet the file belongs to. For example, we'd have

Stuff.kt

that'd default to

commonMain

,

Stuff.js.kt

in the

main

directory that'd be part of the

jsMain

sourceSet,

TestWhatever.js.kt

in the

test

directory would be part of the

jsTest

sourceSet, and

Stuff.darwin.kt

in the

main

directory would be part of the custom

darwinMain

sourceSet. That also makes me think about how

.main.kts

,

.gradle.kts

and

.whatever.kts

files all resolve different symbols based on their extension.

There are updates of the proposal based on your feedback! The main change is that we moved from confusing 

T!!

 syntax to a limited version of intersection types – 

T & Any

. It’s likely that at some point we’ll have full support for intersection types and then it would be just a special case that doesn’t deserve special syntax because it seems that the only real-world use-case we have by now is overrides of annotated Java.

Hey everyone 👋 Has there ever been any discussion to allow for passing regular lambdas where lambdas with receivers are expected? Effectively, ignoring the receiver of the lambda since it’s unused. See snippet below for example. This would be similar to the current functionality that allows for regular lambdas

() -> A

where

suspend () -> A

is expected.

Hello everyone! I think I have found a gap in the standard library and I would like to make a design proposal. Although I have read https://github.com/Kotlin/KEEP and checked current in-progress KEEPs, it is not clear to me if I should open an issue or a pull request first (or both). Could someone guide me on how to start my proposal?

Wouldn’t it be nice to be able to short-circuit functions and constructor calls when one of the params is null 👀 Has something like this been proposed? I’m not sure what to search for in YouTrack 😅 https://twitter.com/pablisc0/status/1432981029812322306?s=20

Anyone else feel this (

trySingle

for collections) would be useful as part of the stdlib? Or have any alternate solutions? 🙂

fun doSomething(customerId: Int) {
   val user = when (val result = fetchExistingUsers().trySingle { it.id == customerId }) {
      is MultipleFound -> error("Duplicate users for single ID")
      is NoneFound -> createUser()
      is Single -> result.single
   }
}

Proposal: Add suffixes for smaller primitive numbers Currently, you can specify 3 primitive types will a character suffix: • Double (1d) • Float (1f) • Long (1L & 1uL) It would be nice to be able to do the same for smaller types • Byte (1b & 1ub) • Short (1s & 1us) • Int (1i & 1ui)

Happy to create a formal proposal, and it’s totally possible I’m overlooking something, but I’d like to check if partial interface implementation delegates is something that’s achievable. Here’s a sample:

// delegation as of now:

interface A { fun foo() }
interface B { fun bar() }

class AImpl() : A { override fun foo() = println("default foo") }
class BImpl(private val a: AImpl) : B, A by a { override fun bar() = println("bar") }

// delegation after proposal:
interface A { fun foo() }
interface B : A { fun bar() }

class AImpl() : A { override fun foo() = println("default foo") }
class BImpl(private val a: AImpl) : B by a { override fun bar() = println("bar") }

Hope this makes sense. The benefit is that

BImpl

does not have to explicitly rely on interface

A

.

Proposal: Add a

.=

operator I'm not sure if this use case will be covered by the deep immutability enhancements that have been mentioned. The new operator would serve the same purpose to the dot operator that you get with appending

=

to other operators (e.g.

+=

,

/=

, etc.) Basically, allow replacing things like

position = position.copy(y = 10)

with

position.=copy(y = 10)

Any reason this is not added?

fun String.remove(value: String): String = replace(value, "")

If I have a function

fun foo(a: Int, b: Long, c: Double)

and a variable of type RequestBody

data class RequestBody(val a: Int, val b: Long, val c: Double)

and I call it like this:

foo(requestBody.a, requestBody.b, requestBody.c)

It would be nice if the spread operator worked on these arguments (not just varargs) so that I could do this:

foo(*requestBody)

Or is there some existing way that this can be done in a succinct way?

I'm curious, has anyone ever proposed anything like this before?

class MyGenericClass<interface I: SomeInterface>(): I {...}

Essentially, allowing us to declare a generic type I as an interface -- this allowing classes or other interfaces in the scope of the type parameter I to inherit from I. I've run into a few circumstances where I find myself wanting something like this -- e.x. when I depend on a generic interface, and then I want a class to extend that interface so that within the class I can access that interface's methods/properties directly, rather than by referencing the interface itself, e.x:

class MyView<interface I: IMyViewModel>(val vm: I): I by vm { ... }

"View" here (Maybe not the best word) being in a general sense, not an Android View -- something that subscribes to the view model events, and updates the UI accordingly.

allow

lateinit

for properties of non-primitive inline/value types

@JvmInline
value class Id(val value: String)

class MyClass {
	lateinit var id1: String //this is fine
	lateinit var id2: Id //so this should be too
}

Would there be any interest in providing a mechanism to make a foreign type implement an interface?

I just noticed ECMAScript 2021 added exactly this with their "logical nullish assignment"

??=

operator. You can read about it here on MDN. Based on this I'd like to restart discussion of the idea for Kotlin. It would function pretty much exactly as the MDN page describes.

Wondering what others think about whether it should be possible to implement a sealed interface that exists in a different package by delegation. It would still ensure that the implementation remains the same as one that exists within the same package as the sealed interface.

Has there been any prior consideration into extending smart casting to support type parameters, such that something like the following could be possible? (Or is some variation of this already possible?)

sealed class Foo<T> {
    object FooBool : Foo<Boolean>()
    object FooInt : Foo<Int>()
}

fun <T> match(x: Foo<T>): T = when (x) {
    is Foo.FooBool -> true
    is Foo.FooInt -> 42
}

file-private should have its own keyword so we can designate class members as file-private

package a

class B {
  // only accessible from within this file
  file-private val priv = 123
}

fun c(b: B) {
  println("I can access ${b.priv}")
}

Something like the "with statement" in Koka could drastically reduce the number of nested curly braces in some situations. https://koka-lang.github.io/koka/doc/book.html#sec-with Something like this:

fun example() {
    wrapped with with(SomeDSL)
    dslCall()
}

desugars to:

fun example() {
    with(SomeDsl) { 
        dslCall()
    }
}

Wouldn’t it be great if I could easily create an immutable version of an instance of a data class with mutable properties? I wonder how that could be done. It’s not easy, but it would be really cool if I could define something like a

MutablePerson

, and it would then automatically have a method

toPerson(): Person

.

Proposal: adopt Compose conventions for enums, singletons and constants. Why? There's no need to call the developer attention SCREAMING_ON_CODE_THAT_CANNOT_CHANGE. A

const val

will never change. An enum member will never change. There's nothing to pay more attention here than any other symbol (maybe it should actually be the opposite, a top-level

var

should have this convention because that can lead to issues -- although I think in this case it should also be prefixed with

CODESMELL_

😁). My guess is this convention came from Java, which came from C/C++, where developers reading macro usages should immediately know it would expand to arbitrary code, but this is not the case in Kotlin.

hi! I’ve spent some time thinking about how we can improve

is

tests in Kotlin by adding some lightweight type refinement on matching; this is what I came up with https://gist.github.com/serras/ee07f36b38756f076d654496a3d2eb61 I would love to know what the community thinks about it; it seems waaay more simple than what Scala does, but it still unlocks quite some power in the type checker

any chance

sealed fun interface

will be added in the future?

Octal notation should be more helpful than just flagging a compilation error; parsing Octal is an ugly hack in kotlin. having a IDE/compiler expression to recognize the prefix and tell you "something is here, and you can't use it" is suboptimal.

Would it make sense for Kotlin to provide constant array literals? E.g.

const val arrayLiteral = ["books", "default"]

could then be used in an annotation like

@CacheConfig(cacheNames = arrayLiteral)

.