I saw this mentioned in another channel but not discussed here-- Lambdas that disallow capture. Use

{{}}

instead of `{}`:

chain.map{{ input -> /* capture throws a compiler error */ }}

Are there any plans for adding a 'mutableIncrement' operator? Because right now I am not able to write my own extension function for this use case that would behave like this:

val foo = AtomicInteger(0)
foo++

Current

increment

operator would allow me to work only with

var foo

, but this is obviously not what I want. In my use case I want to launch N coroutines and show a progress bar with how many of them have already finished (tracked in the

foo

AtomicInteger)

Here’s a strange case that I just ran into. Even though the language forbids overriding inline methods, it’s actually possible here. The method signatures differ by the input lambda type, which is erased at runtime, and by the return type.

Idea: Passing an array to a

vararg

parameter using

vararg

keyword. Reason: Make code easier to read & understand (one keyword in both locations), simplify language (no extra unary

*

operator needed) Esp. helpful for people who are new to Kotlin or have only rarely if ever use spread operators in other languages. Example:

ByteString.of(*buffer.toByteArray())

->

ByteString.of(vararg buffer.toByteArray())

At the declaration-site

vararg

denotes "variadic number of parameters". At the call-site

vararg

denotes "variadic number of arguments".

I see myself using

data class

a lot - but mostly for automatically generating

toString()

and

equals()

, sometimes

hashCode()

, rarely `copy`(). I never care about

componentX()

for destructuring but noticed that their existence can be confusing to people (and me changing the order of properties breaking their code). The general idea of having less boilerplate for simple repetitive tasks / common idioms is good. It would be awesome if developers could express with more detail what auto-generated functionality is actually desired and which is not. This also makes the actual capabilities and the intended usage of a class clearer than using a

data class

that adds functionality which may not always make sense. I know that I may be misusing data classes here and I guess I'm not the only one using them to avoid manual and repetitive implementation of

toString()

,

equals()

and

hashCode()

. In addition to having less boilerplate the compiler can generate well-optimized implementations which are even more work & code when done manually (think for example a good

hashCode()

implementation over multiple properties without boxing or platform dependency à la Java's

Objects.hashCode(…)

). I like Swift's approach where a developer can for example state that a

struct

is

Equatable

or even

Hashable

and if all properties are too then the implementation is auto-generated by the compiler. Kotlin could do the same to make adding these method simpler. E.g. if I add

: AutoEquatable

to a class the compiler could auto-generate

equals()

for me over all properties - just like a data class and potentially using the same constraints as for these. Same for

AutoHashable

->

hashCode()

,

AutoStringConvertible

(or alike) ->

toString()

,

AutoCopyable

->

copy()

and

AutoDestructurable

->

componentX()

. A

data class

is automatically

AutoEquatable

,

AutoCopyable

,

AutoDestructurable

,

AutoHashable

and

AutoStringConvertible

. @gildor suggested to use annotations instead of interfaces, which is also a good option. There would be no need to change the language itself. The Standard Library would merely add a few interfaces and the compiler use them for auto-generating some code. Another alternative could be to use data classes but opt out to some of its functionality, e.g.

data(nocopy, nocomponents) class …

. That would require syntax and language changes though. What do you think? 🤔

Any reason why users of inline classes cannot use @PublishedApi internal constructors? I see them in the Result<T> KEEP and I think "forcing" Kotlin users to use a factory function to get an instance has many use cases. Currently I've resorted to just marking the constructor deprecated and hoping users don't use it/

Annotations that set a default function for overload ambiguity

@AmbiguityDefault
operator fun Foo.plusAssign(other: Foo)

fun repeatReversed(times: Int, action: (Int) -> Unit)

in stdlib?

Proposal: Allow

inner object

On several instances I've come across a situation where I have code like:

class Parent {
    val child: Child = Child()

    inner class Child
}

Where it would be preferable to have:

class Parent {
    inner object Child
}

The main advantage I'm looking for (other than readability) is locality: - Every

Parent

has in instance of

Child

-

Child

is a well defined type - You cannot create new instances of

Child

with something like

parent.Child()

try {
    ...
} catch { e ->
    ...
}

try foo() catch { bar(it) }

try foo() catch bar()

or as @Marc Knaup suggested:

try foo() else bar()

instead of

catch

in the event you are ignoring the throwable

a way to place inner classes or functions thereof in a different file for better organization, potentially via annotations:

import foo.Foo
@innerOf(Foo)
inner class Bar

import foo.Foo
@innerOf(Foo.Bar)
fun bar() = "blah"

The same may then be extended to sealed classes

I’ve found these syntaxes in Google’s Android repository. Is this a valid syntax? Or is there a possibility in the future?

<SemanticsComponentNode
    container
    explicitChildNodes
    enabled
    checked
    selected
    button
    header=null
    textField=null
    focused=null
    inMutuallyExclusiveGroup
    obscured=null
    scopesRoute=null
    namesRoute=null
    hidden
    label
    value
    hint=null
    textDirection
    testTag=(testTag ?: providedTestTag)
    actions>
    TestTag(tag=DefaultTestTag) {
        children()
    }
</SemanticsComponentNode>

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/ui/framework/src/main/java/androidx/ui/core/Semantics.kt#130

Idea: JVM getter name change. Currently:

data class Component(val active: Boolean) {
    val getList get() = listOf("empty")
    val isPoorlyNamed get() = 10
    val isCorrectlyNamed get() = true
}

JVM code:

Component component = new Component(false);
component.getActive();
component.getGetList();
component.isPoorlyNamed();
component.isCorrectlyNamed();

Proposal: To better match Java Bean naming conventions:

val active

->

boolean isActive()

- Boolean return maps to “isProperty”

val getList

->

List<String> getList()

- Already prefixed with “get” -> leave it

val isPoorlyNamed

->

int getIsPoorlyNamed()

- Prefixed with “is”, but isn’t a boolean -> add “get” prefix

val isCorrectlyNamed

->

boolean isCorrectlyNamed()

- Same as today

Is there any ongoing work on the Result type to make it more available (without the current restrictions) ? I'm also mostly interested in having Result with the languages improvements mentioned in the "integration into the language" section (https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#integration-into-the-language)

a way for interfaces and superclasses to define that an inheritor must have static members of its own of some type. AKA you have to have an object that extends as such

Proposal: make

suspendCancelableCoroutine

a part of the language instead of

suspendCoroutine

as a more general and tweakable language unit.

Replace

where

syntax current:

class Foo<A, B>(val a: A, val b: B) where A: Bar, A: Baz

proposed:

class Foo<A: Bar & Baz, B>(val a: A, val b: B)

not like

&

is getting any use in Kotlin anyhow...

Oh boy, multiple inheritance! Already "achievable" like so:

interface Bar {
    val bar: Int
    companion object {
        operator fun invoke(bar: Int) = object : Bar {
            override val bar = bar
        }
    }
}

interface Baz { 
    ...same as how Bar is implemented 
}

class Foo(bar: Int, baz: Int): Bar by Bar(bar), Baz by Baz(baz)

but wouldn't it be nice to just:

class Foo(bar: Int, baz: Int): Bar(bar), Baz(baz)

Reference properties using

by

,

is

, or something like that current:

var foo = 3

var bar
    get() = foo
    set(v) {
        foo = v
    }

proposed:

var foo = 3
var bar by foo

I created an issue for a potential optimization: It seems that when there is a method with

vararg

and 0 arguments, a

new Object[0]

is allocated every time, according to the decompiled code https://youtrack.jetbrains.com/issue/KT-32474

Proposal: apply operator I find myself often in the situation where I create a new thing and have to call a single method on it as part of setting it up. The common form is to use

val thing = Thing().apply { setup(...) }

. While this is simple enough, I do it so often it would be nice to have an operator for it, that calls the function, but ignored the return value and returns the receiver instead, so I could do something like

val thing = Thing()&.setup(...)

This may just be to my style of programming, but I figured I'd throw it out there to see if anyone else is interested.

foo if (condition)

syntax, like exists in Ruby and other languages. It is superior to

if (condition) foo

in that it doesn't allow for multiline, and avoids the problem of:

if (foo)
    bar
    baz // not in scope

Also maybe drop the condition's enclosing

()

Proposal: Add InvocationKind.LAZY to contracts to specify that a lambda parameter will not be called before its declared method has returned. Use case: See sample code at https://pastebin.com/8TFJH437

This message was deleted.

Can generic parameters be reified at class level? https://discuss.kotlinlang.org/t/can-generic-parameters-be-reified-at-class-level/13791

Type inference for function argument with default value.

// Inferred as x: String, y: Int = 2, z : String = "hello"
fun foo(x : String, y = 2, z = "hello"){
}

would be nice if range checks caused smart casting:

if (pin?.length != 36) throw Exception()
// pin is smart cast here

if (pin?.length !in (8..36)) throw Exception()
// pin is not smart cast here

sometimes I wish I could destructuring directly to existing `var`s

var hovered = false
var held = false
if(..) {
    val (_, ho, he) = buttonBehavior(columnHitRect, columnId)
    hovered = ho
    held = he
}

Idea that myself and @Charles have been discussing: a new keyword on function definition to automatically make the first operation of said function be a call to

super

. For example:

override fun onDestroy() {
    super.onDestroy()
    channel.close()
}

could become

super fun onDestroy() = channel.close()

The

override

word becomes optional, since the call to

super

only makes sense in the context of functions that are being overridden.