Kotlin 1.4 will optimize

trimMargin

,

trimIndent

at compile time, see https://youtrack.jetbrains.com/issue/KT-17755 I thought this would also allow for const strings using that. I’m guessing this will be the next step.

new Proposal: Error-able Types (yes, the name sucks, that should obviously be changed) we have

nullable

types, which actually are a big reason why Kotlin is loved so much. but as soon as more complex Problems come into play, we have to go to rather ugly exception-style code, or use

Either

/

Try

types from libraries like arrow-kt ( or create them ourselves) while using

Try

and

either

types isn't a big problem by itself, it quickly looses a huge amount of Kotlins consiseness, because it makes you write

kt
val someTry: Try<List<Int>> = someTryReturner()

val result = someTry
  .map { it.map { it * 2 } }
  .map { it.sum() }
  .map { "result is ${it.toString()}" }
  .getOrElse { exception -> "There was an error: ${exception.message!!}" }
println(result)

This would be a lot easier when written with the nullable type:

kt
val someNullable: List<Int>? = someNullableReturner()

val result = someNullable
  ?.map { it * 2 }
  ?.sum()
  ?.let{ "result is ${it.toString()}" }
  ?: "There was an error, but i don't know what kind of error D:"
println(result)

Here were obviously missing out on the error information. because of this, i propose to support a

Result<E, V>

-like type, that behaves like the already existing nullable. my proposed syntax would look like this:

kt
val someExceptional: List<Int>?? = someExceptionalReturner()

val result = someExceptional
  ??.map { it * 2 }
  ??.sum()
  ??.let{ "result is ${it.toString()}" }
  ?: { exception -> "There was an error: ${exception.message!!}" }
println(result)

this would make code a lot more readable, and could strongly help to encourage developers to actually handle their errors properly. one additional thing that should be included with this would be a

runExceptional

function, that takes a lambda-block that could throw an exception and turns it into an exceptional type. another possibility would be to actually have a more terse way of turning a throwing function into an exeptional:

fun thisThrows(): String {
  throw SomeException()
}
val someExceptional: String?? = thisThrows??()

the questionmarks could directly turn any function that could throw into an exceptional-type. (this syntax is not possible, as it would be ambiguous in situations where you had a

(() -> T)??

value that gets executed, but there should be a solution to that problem.

try without catch or smth like

tryOrElses

->

val t = try{...}

<- null on fail

val t = try{...} else X

val t = try{} ?: X

small wish, I'd like to have the possibility to

init

without body, eg:

init = bar()

Here is an artical in witch I am proposing the notion of const class and const capturing lambda, and why I think it matters: https://itnext.io/designing-a-kotlin-memory-safe-mode-c76c06317c3e

Although Kotlin's Elvis operator has cleaner semantics (

if (c) a else b

) than the classic one (

a ? b : c

) it's still a branching (#if-considered-harmful), it's awkward to write and it is hard to use with nesting. Why not to provide a functional programming style operator

eitherOr(c, a, b)

, implemented as a function:

fun <T>eitherOr(condition: Boolean, first: T, second: T) : T {
    return if (condition) first else second
}

After all, we already have things like

min(a,b)

, `or(a)`etc.

Untitled

object-destructuring-by-name_kt.kt

^^ One thing where JavaScript is better than K is that it has object destructuring by name. Kotlin has only destructuring by component order … which is ok-ish in some cases but especially not good if all your properties are String. … or at least this is what I thought and then I realized we can do this in Kotlin too! The pattern is to use

val (my, destructuring, declaration) = with(object) { Tuple(my, destructuring, declaration)

It’s stil position based obviously since this is what Kotlin support. But in this case it doesn’t matter because the order of arguments is declared in line, not in another class. It’s also much more general, it works with much more than “the properties of data classes”. We can put whatever we like in the lambda and transform it to a tuple. Update: https://youtrack.jetbrains.com/issue/KT-19627

swift initializes nullable variables automatically to

null

, could kotlin do the same?

Hallo, would this be the right channel to ask questions about inline classes?

Proposal: the ability to use

by

on constructor arguments for delegation.

class Foo(val bar by Lazy<Bar>) { ... }

would be syntactic sugar for

class Foo(barProvider: Lazy<Bar>) {
    val bar by barProvider
    ...
}

This pattern appears over a thousand times in the codebase I'm working on, and cutting out the declared

barProvider

middle-man would make switching between

Bar

and

Lazy<Bar>

extremely simple.

Hi, wondering whether some kind of shorthand might be useful for exposing a value of one type as a super-type with a more restrictive interface. E.g.

val mylist : MutableList<Thing> exposedas List<Thing>

- keeping the mutable functionality private to the class, but exposing the immutable interface. What do you think?

Not sure whether this was already discussed, but it would be nice to be able to overload the comparison operators (<, >=, ==, etc) other than using compareTo (that must return an Int). I would love to have this for a DSL that is used to write some conditions that can be checked only later in the future. I have this

BooleanExpression

object than can be returned by some call, e.g.

myFutureValue.isGreaterThanOrEquals(aStaticValue)

. It would be nice if instead I could write that using

myFutureValue >= aStaticValue

Would it be feasible to declare nested classes in a separate file? For example: I would like to have

MyViewModel

in one file, and

MyViewModel.State

in another file?

Suggest adding

fun Pair<A, B>.flip(): Pair<B, A> = Pair(second, first)

to standard library

package-wide suppression:

@package:Suppress("unused")

useful in spring, for example

For DSLs, it would be nice to be able to overload

ReadWriteProperty#setValue

so that we could set a variable from different types. Something like this:

import kotlin.reflect.KProperty

interface Named {
  val name: String
}

class MyClass {
  var name by NameDelegate("foo")
}

class NameDelegate(private var name: String) {
  operator fun getValue(thisRef: MyClass, property: KProperty<*>): String {
    return name
  }

  operator fun setValue(thisRef: MyClass, property: KProperty<*>, value: String) {
    name = value
  }

  operator fun setValue(thisRef: MyClass, property: KProperty<*>, value: Named) {
    name = value.name
  }
}

fun main() {
  val namedImpl = object : Named {
    override val name: String = "bar"
  }

  val myObject = MyClass()
  myObject.name = "bar" // this compiles
  myObject.name = namedImpl // this does not compile
}

fun <K, V> MutableMap<K, V>.putAll(vararg pairs: Pair<K, V>): Unit

kinda strange it's not in the stdlib already...?

i should probably be thoroughly shot down for this idea, but: casting maps to data classes or interfaces

data class Foo(val foo: Int, val bar: Int)

val foo = mapOf("foo" to 1, "bar" to 2) as Foo

implicit

this

argument for when statements:

fun Any?.isFalsy = when {
    null -> true,
    etc
}

Building upon that, I'd prefer

when (stuff)

to allow just calling methods, adding the receiver to the branch conditions, or have

stuff.when

do that as a new special syntax. (Thinking about how it would translate to actual uses cases, I think I prefer that latter approach)

Hey all, I was working on a project of mine and I needed a function which would intersect two collections based on transform functions provided on both or single collection. But couldn't find any in kotlin stdlib, I think it's not there, so I've created a custom extension function to achieve this. So here's the proposal. I would like to contribute this new extension function in collection standard lib. Will add proper proposal for this if you guys think it's worthy of contribution. By the way this would be my contribution in kotlin if it got accepted. Thanks. Found about this channel from https://github.com/Kotlin/KEEP.

It would be nice if we could copy documentation from another method:

/** 
  * @copy Foo.bar()
  */

For methods that do almost identical things but take slightly different parameters. For different params, a

@param

tag on the method would override whatever is present on the comment being copied from

How would I go about proposing a KEEP for something in the issue tracker? I'm really interested in seeing setter overriding be possible.

I see a very common pattern of using 2 properties, private and public, when exposing a mutable container as a read-only interface. Example with Android

LiveData

(a kind of observable):

private val _volume = MutableLiveData(0)
public val volume: LiveData<Int> = _volume

Example with lists:

private val _users = mutableListOf(user1)
public val users: List<User> = _users

Are there any ideas that are on the table that would simplify those patterns or allow them to be encapsulated with property delegates?

My syntax suggestion for that -

private val users = MutableLiveData(0)
  exposeas LiveData<User>

Since Kotlin 1.3 the

fun main(args: Array<String>)

function is permited to be simplified as

fun main()

(when the entry arguments are not used). My suggest is that, when the arguments of the entry

main

function ARE used, the IDE/Compiler may accept just

fun main(args)

, assuming the type of

args

would be

Array<String>

.

if we have set/get operator on not nullable elements (

!!

) we shall also have it after

.?

Proposal: per symbol name experimental opt-in. Use case example : I want to use

kotlinx.coroutines.invoke

for

CoroutineDispatcher

without having to use either of these two inconvenient options: 1. Adding

@UseExperimental(ExperimentalCoroutinesApi::class)

at each use-site 2. Opting-in for all

@ExperimentalCoroutinesApi

and being bitten later when other experimental APIs change that I didn't see coming. I'd want to be able to opt-in for these in Gradle config (or compiler config) in a way or another, I can search for ideas on how to define it. The fully qualified name (or a pair of imports + symbol names) would be enough, opting-in for all functions overloads, in a KDoc fashion.