I have modelled a scenario where I have a

Controller<S>

and a

View<S>

and I want this to work as a cyclic dependence where the controller depends on the view indirectly. For that I was thinking on defining a

Provider

that takes a concrete controller and creates an instance of view with that injected. Currently it looks like this:

fun interface ViewProvider<C : Controller<S>, S : State> {
    fun get(controller: C): View<S>
}

It feels redundant that I have to locally specify

S

, since

Controller<S>

already does that job. For example:

class AController : Controller<A>
class Provider : ViewProvider<AController, A>

S

here can only be

A

, since

Controller<S>

is invariant in

S

, and here

S

is

A

. Specifying

A

looks somewhat redundant. Could the type parameter here be inferred so the client code becomes less redundant?

I'm curious, if there has ever been a proposal for, or interest in, "named" destructuring Kotlin has your typical destructuring that's also seen in a number of other languages. it's positionally based:

data class foo(val i: Int, val s: String)
val (s, i) = foo(5, "hello")  // Reverse order you might expect, s is an int, i is a string

One could imagine doing it by name of the field instead. Imagine we use =, to piggy back off of the analogy between positional and named arguments

val (=s, =i) = foo(5, "hello")  // okay, now it matches by name instead, so we create a variable s that's a string, i that's an int

It would require that there was a property with the name of the variable. if not, compiler error. behind the scenes it just gets translated to:

val unusable = foo(5, "hello")
val s = unusable.s
val i = unusable.i

Advantages would be that it would allow destructuring "safely", without worrying about getting the order right. It's a relatively minor/simple thing to implement, easy to understand at first glance, and has a similar benefit for correctness as named arguments over positional arguments.

Do we already have a proposal for the spaceship operator?

<=>

would be nice together with a corresponding

Ordering

Enum.

when (a <=> b) {
    Ordering.Less -> {}
    Ordering.Equal -> {}
    Ordering.Greater -> {}
}

Proposal: externally-defined companion objects. Allow defining companion objects externally, similar to what Scala does (https://docs.scala-lang.org/overviews/scala-book/companion-objects.html). Same motivation from my previous (https://kotlinlang.slack.com/archives/C0B9K7EP2/p1597588637286600) proposal: • Allowing to add extension functions for Java types (solves most-voted YouTrack issue: https://youtrack.jetbrains.com/issue/KT-11968). • Improving consistency with the way non-companion extension functions work, as they don't require special declarations on the class being extended. Proposed syntax:

package com.fasterxml.jackson.module.kotlin

import com.fasterxml.jackson.databind.ObjectMapper

companion object ObjectMapper.Kotlin {
    fun forKotlin(): ObjectMapper = ...
}

// Would then also work
fun ObjectMapper.Kotlin.withAlphabeticallySortedProperties(): ObjectMapper = ...

// Usage from another file
import com.fasterxml.jackson.module.kotlin.ObjectMapper.Kotlin

fun main() = ObjectMapper.forKotlin()

This eliminates the need to add empty

companion object

declarations in classes solely for the purpose of allowing extension functions and allows defining extensions for Java types. The difference between internally and externally defined companion objects would be the ability to access private and protected members. For more information on use cases and problems of the current alternatives, see my previous proposal (linked above).

is there any consideration towards allowing break/continue inside lambdas, that are in

inline

functions with loops? Since

return

is allowed inside lambdas in that situation, it seems surprising that break/continue do not work. It also limits the language's ability slightly to "extend" the built in loops.

Proposal: allowing default values for infix functions making it possible to use infix notation almost like a "postfix" notation Use case, when building a DSL that requires "chaining words", like in SQL, the last "word" requires garbage input in order to compile

class postgresql(function: postgresql.() -> Unit) {
		
        ....
        
        infix fun postgresql.DESC(value: Unit): postgresql {
			return this
		}
	}

	fun main() {
		postgresql {
			SELECT (
				ListingTable::section, ListingTable::id,
				ListingImageTable::name, ListingImageTable::listingId
			) FROM (
				ListingTable::class
			) LEFT JOIN (
				ListingImageTable::class
			) ON (
				ListingTable::id == ListingImageTable::id
			) WHERE (
				true
			) ORDER BY(ListingTable::modified) DESC Unit
		}

Are there any proposals to improve ergonomics for updating nested members of immutable data classes? I've seen lens libraries can help a bit but they only go so far given the tools the language currently provides

Not sure what the best channel for this is, but it’s a compiler issue, so language-proposals seems the closest fit… In Java 11, the functions

List.of(…)

and

List.copyOf(…)

create immutable lists. The Kotlin equivalents,

listOf(…)

and

anIterable.toList()

actually create mutable lists but return the List interface that doesn’t allow mutation. In Kotlin, that’s not a problem — lists are processed by being transformed with map/flatMap/filter/etc. and so nothing holds on to a reference to mutable lists and aliasing errors do not occur. However… when you pass the Kotlin List across the Java interop boundary, Java sees it as a mutable java.util.List and, because the Kotlin list is actually mutable, Java can mutate a list through an interface that the Kotlin type system considers to be unmodifiable. Worse, the Kotlin code is now more error prone than the Java code, because the Java code would fail immediately if you tried to mutate the immutable list, but the Kotlin code allows that list to be mutated. Suggestions: • when the kotlin compiler is targeting JVM version 11 and above, translate Kotlin’s listOf and toList to the JDK List.of and List.copyOf functions. • on 1.8 and below, wrap Kolin Lists with Collections.unmodifiableList (or some equivalent in the Kotlin runtime) when being passed across the interop boundary.

Hello, everybody! I just arrived at this channel so it's possible that someone has already asked this question before. But, I was wondering if anyone else would like to have n-uples in return statements in kotlin(swift style) like this:

func returnMultipleValues() -> (String, Int, Double) {
    return ("Swift Tuple", 12, 3.14)
}

PS. I know how to use lists hahaha, I just think that it would be a lot easier this way

Somewhat related to above, but has there ever been discussion of variadic generics in Kotlin? Even if it were done, say, only for inline functions, the same way that

reified

is. I think that would be super useful. That could allow simple tuples, and non-neutered implementations of things like zip, for example.

Proposal: class as a use-site annotation target for top level functions. Example syntax and very basic potential use case, using Spring Boot:

@class:Controller
@GetMapping("/test")
fun singleFunController() = "viewname"

At the moment all top level functions in a file compile to the same class, so any with a class annotation would have to compile to its own class, presumably with a name based on the function name,

SingleFunControllerKt

or something. Probably a little limited in use, but it would be neat.

Proposal: keyword to expose a val/var as an interface or a parent class. Having to write private backing properties requires a lot of boilerplate especially if you have many properties to expose.

class Test1 {
    private val _subject: Subject<String> = BehaviorSubject.createDefault("Test")
    val subject: Observable<String> = _subject
    fun onEvent(event: String) = _subject.onNext(event)
}

class Test2 {
    val subject: Observable<String> = BehaviorSubject.createDefault("Test")
    fun onEvent(event: String) = (subject as BehaviorSubject<String>).onNext(event)
}

class Proposal {
    exposed:Observable<String> val subject: BehaviorSubject<String> = BehaviorSubject.createDefault("Test")
    protected exposed:Observable<String> val subject2: BehaviorSubject<String> = BehaviorSubject.createDefault("Test")
    fun onEvent(event: String) = subject.onNext(event)
}

fun main() {
    // should all be of type Observable<String>
    val test = Test().subject
    val test2 = Test2().subject
    val proposal = Proposal().subject
}

Test1 shows the private backing property method. Test2 shows using the val as the interface / parent class and casting everywhere with as. Proposal show an example syntax of how this could be made less verbose and more readable.

I don't know if this has been discussed before but I couldn't find it anywhere so... I'd really like to make comparisons and assignments a bit more idiomatic with the following changes: Comparisons: Similar to Python, numeric comparisons should be more mathematical. Like

if (1 <= x <= 10) // do something

This would greatly improve readability and would reduce bugs since it's easier to understand that x is within the boundaries of 1 and 10. Way better than the current equivalent:

if (1 <= x && x <= 10)

. The "&& x" is just boilerplate code here... Assignments: For assignments I'd like to have the possibility of assigning an assignment to another variable. E.g.

myObject.apply { inputFee = outputFee = 1.0 }

In this case both inputFee and outputFee would be set to 1.0 (or more like inputFee would be set to outputFee). This is useful for mapping code so it makes most sense for properties. I could also imagine like saving a property to a variable before it is modified in someway. Maybe like this:

val before = myObject.counter = someArg
myObject.count() // modifies counter
val difference = myObject.counter - before

What do you guys think?

The ability to change mutability (or reassignability) without coming up with a new name like in Rust would be great. fun f() { var x = 0 val x = x }

I wish that if you declared the primary constructor of a data class private, its copy method would be private too.

Probably too late now though…

This message was deleted.

This is more thinking out loud than a language proposal... Default arguments are great. But let's compare them with a builder pattern for a second:

Something.Builder()
   .apply {
     foo("mandatory argument*)
     val barArg = grabBarArg()
     if (barArg != null) {
        bar(barArg)
     } else {
        // do nothing, leave the default
     }
   }
   .build()

With the default parameters we don't have the option of leaving the default like that;

Something (
    foo = "mandatory argument",
    bar = grabBarArg() ?: _
)

I think it would be helpful to have a way of explicitly saying "use default" like passing a

Nothing

? Or in some other similar way? When I'm this situation if i have control on the class i create a secondary constructor, but it could be helpful, i think, to have a way to provide the default from the caller. It might also improve kotlin / java interoperability.

Why isn't the

Number

interface extending

Comparable

? Being a number always superimposes an ordering imho.

In yesterday’s presentation by @elizarov regarding the potential future features of Kotlin @with was mentioned. We were exploring changing arrow meta @Given to this proposal but we quickly encountered as so have others the limitation with generic type args as in @with<ComparableA> or similar where A is in the function it decorates as a generic arg. We found this issue where this is being discussed https://youtrack.jetbrains.com/issue/KT-42435 by @etolstoy as well. Has there been any thoughts as to how to deal with these cases or does anyone have any ideas as to how we can enable these additional receiver types that are generic over annotations that need to be concrete on their type? Also interested in thoughts about how to support multiple type args since `@with(Rec1, Rec2…). Thanks for any ideas 🙏 .

Are there any proposals for a way to avoid having to specify params to be passed to parent classes constructor? for example if we have

abstract class Foo(val id: String, val f1: String, val f2: String)
class Bar(id: String, f1: String, f2: String, val other: String): Foo(id, f1, f2)

I want to avoid having to specify the same props (

id

,

f1

,

f2

), and better yet would like to reuse the documentation across all the subclasses

I just thought that it would be nice if we could get access to the eventual exception in the

finally

block. I often log timing, exceptions and cancelations for a block of code. With the current approach I’d have to duplicate logging code in

catch

clause(s) and at the end of the try block in the success case. I’d also have to use

.also { … }

in the try block to not change the return value. It would be much easier if I could something like

val start = TimeSource.Monotonic.markNow()
val x = try {
   lotsOfLogic()
}
finally { e -> // Throwable?
    // complicated logging with or without exception
}

Without:

val start = TimeSource.Monotonic.markNow()
val x = try {
   lotsOfLogic().also {
     // complicated logging without exception
   }
}
// multiple catch clauses would duplicate logging
catch(e: Throwable) {
    // complicated logging with exception
    throw e // rethrow needed
}

I’m working with multiplatform and I’ve found the problem with logging. What do you thing about this proposal? -------------- A developer of a multiplatform project has to use some external library or write its own implementation (with slf4j/println/NSLog as an actual implementation). For example, ktor library uses slf4j for JVM target and println for others target. It’s better to use a common library. Example (the best but not good enough): https://github.com/MicroUtils/kotlin-logging/

This is happening to me multiple times.. I find

when

and the possibility to declare some

val

quite limiting:

val platform = when(val os = DefaultNativePlatform.getCurrentOperatingSystem()) {
    os.isWindows -> 0
    
}

if I declare something like that,

when

expect exclusively matches against

os

Type I'd like something more broad

I say let’s get rid of the idea of multiple receivers 😄 https://youtrack.jetbrains.com/issue/KT-42435#focus=Comments-27-4466122.0-0

With respect to Result, I know a concern is that it erases the type of the error. Has there been consideration to making Result an interface, and having a derived class:

interface Result<out T> : Serializable
inline class Outcome<out T, out E: Throwable> : Result<T>

If you do something like this, then you can use

Outcome

as local error handling wherever you want to keep the type. And, if you need to collect errors from multiple sources, you just let Outcome up-convert to a Result. Things like

runCatching

could construct an

Outcome<T, Throwable>

(i.e. the most general case of Outcome) which could then be allowed to up-convert to Result instantly (leaving their API identical to now)

Wouldn't it be nice if we could destructure into function parameters?

fun getMarkerLocation(): Pair<Double, Double> { ... }

fun addMarker(name: String, lat: Double, lng: Double, color: Int) { ... }

addMarker(
    name = "marker",
    color = Color.RED,
    (lat, lng) = getMarkerLocation()
)

I wonder if this has ever been discussed.

I wish if there could be a substitute for

@inheritDoc

. Something even more extensible and familiar, more like:

/**
 * @copyFrom SuperClassOrInterfaceManualSelection.someFunctionName
 * // extended docs with other info
 */

• It could be used by IDE to jump into correct definition. • It could be beneficial to follow strict code styles where a KDoc is required on public/internal/protected functions. • It can and also give the user a clue from where the doc is being inherited from, such as if a class has multiple Interface inheritence (and no superclass) with same function defined with different KDoc one can assure the overridden KDoc follows the particular interface. • Same goes (on rare cases) if one wants to inherit KDoc from the interface instead of super class (if class both extend a class and implement interface(s)). Edit: Another idea came in my mind extending the above feature-request/proposal, if there can be pythonic style line selector in

@copyFrom

:

@copyFrom Interface.method[1:5]  // copy/inherit line 1 to 5 (exclusive or maybe inclusive)
@copyFrom Interface.method[2:]   // copy/inherit line 2 to the last line
@copyFrom Interface.method[:6]   // copy/inherit from first line to line 6

// Below are not important part of this proposal, but maybe easier to select from bottom if the KDoc of Interface.method was long enough
@copyFrom Interface.method[:-2]   // copy/inherit from first line to second last line

Apologies for any grammatical errors and/or improper formatting.

I'd like to overload the spread

*

operator, so that this:

val s = "pos (%8.2f,%8.2f), uv (%.6f,%.6f)\n".format(v.pos.x, v.pos.y, v.uv.x, v.uv.y, v.col)

may become

val s = "pos (%8.2f,%8.2f), uv (%.6f,%.6f)\n".format(*v.pos, *v.uv)