I've just seen the new

..<

operator. Will other mathematical range operators considered in the future ? Like open started (

<..

?) Ranges, or fully open ranges (

<..<

?) ? I think both are not very common, but maybe it would make sense to be exhaustive in this matter ? Maybe some mathematical libraries would have use for it ?

Because there is no syntax to specify type arguments for property access If

T

used in receiver then it's always possible to infer

T

from it (because all types in receiver should be inferred before call/access itself) But if

T

is used only in return type then there will be cases when compiler can not infer it, like

val x = something // no information to infer T

context(A, B, C, D, E, F, G, H, I, J)
someFunction() { ... }

with (a) {
    with (b) {
        with (c) {
            with (d) {
                with (e) {
                    ...
                    with(j) {
                        someFunction()
                    }
                }
            }
        }
    }
}

I was thinking

with (a & b & c & d & e & g & h & i & j)

or

contexts (a, b, c, d, e, g, h, i, j)

that automatically generates that nested withs, but that's even messier obviously I've exaggerated the number of params, but if context receivers were to be used as a replacement for dependency injection (which seems like a brilliant use-case), I can easily see the number of params increasing as the number of services in a project increases. For now, the obvious workaround is just stashing all those fields in a single class and doing something like this:

context(Alphabet)
fun someFunction() {
    this@Alphabet.a.doSomethingWithA();
}

with(Alphabet(a = TODO(), b = TODO(), ..., z = TODO())) {
    someFunction()
}

Maybe this can become

context class Alphabet(
    val a: A
    val b: B
    ...
    val z: Z
)

now if you

context(Alphabet)

, it puts all of those fields in context instead of the Alphabet class itself like a data class would have done. Also, if something has

context(A)

, I can just pass the whole

Alphabet

context instead of wrapping the call-site in

with (this@Alphabet.a) { ... }

since Alphabet already contains

A

Why doesn't the Kotlin standard library provide something like Either? They already halfway provide it with Result, but as Result only takes a throwable it doesn't feel very useful. Why not just make Result be Result<out A, out B> ?

I’d love to see

@NoInfer

being standardized. Any plans on that? Often you have to provide something like

someDefinition<Type> {…}

or

resolve<Type> {…}

- where you define something for a specific type. For example: • In dependency injection I want to force an explicit type to be provided. It’s too easy to accidentally infer a wrong type (esp. after refactoring something) and it’ll only result in an error sometime at runtime. • BSON / GraphQL type definitions. Here I want to be explicit for safety. Also, definition blocks can become quite long and if you have many across your project figuring out the type takes a while because it’s implicit. Last but not least type inferences seems to slow down compiler and IDE performance significantly.

I just read carefully what's new in 1.7.0 and after seeing "Allow implementation by delegation to an inlined value of an inline class", I wonder if it would be possible to do the same for (abstract) classes. In this way, unsigned numbers could extend the abstract class

Number

@JvmInline
public value class UInt @PublishedApi internal constructor(@PublishedApi internal val data: Int) : Comparable<UInt>, Number by data

and I'd be super happy because I don't have to create tons of additional and redundant constructors and methods specifically for every single unsigned (in glm)

How about allowing file-private receivers to be used in public functions? I could see this solving the need for a file-private accessibility modifier, and I can't thing of any immediate hard reasons this shouldn't work. I can see it being unintuitive, like accidentally using a file-private receiver and not knowing why it's missing from intellisense in other files, even if the receiver functions have a public modifier. Could be a suppressible warning but then it'd feel like a hack or awkward (I'm assuming

context

here is also an error, but just not reported as one yet since it's a prototype/experimental)

I'm using extensively a trick to return multiple values with zero allocations, it's based on the idea of @louiscad, an example:

class Vec2(val x: Float, val y: Float) {
    inline fun plus(s: Float, res: (resX: Float, resY: Float) -> Unit) {
        kotlin.contracts.contract { callsInPlace(res, kotlin.contracts.InvocationKind.EXACTLY_ONCE) }
        res(x + s, y + s)
    }
}

This code can then be called as

val a = Vec2(0, 1)
val b: Float; val c: Float
a.plus(3) { x, y -> b = x; c = y }

it's useful in hot loops (in 3d real time graphics) or, in Louis' example in Android, where you want to save any allocation you can Now, It'd be nice if Kotlin may automatically destructurize a lambda placed at the last place in a function signature without any allocations. That is something like:

val a = Vec2(0, 1)
val (b, c) = a.plus(3) { x, y }

while underneath the compiler would automatically apply the code as shown in the first example Another nice advantage, which would come for "free", it's essentially using an argument parameter as a return one, overcoming the JVM limitation of not considering the return type as part of the function signature

Maybe I'm missing something, but shouldn't there be an

inner object

declaration? Something similar to:

class Foo {
   val num = 1

   inner class Bar {
      val one = "something $num"
   }

   val bar = Bar()

   init {
     // use it:
     println(bar.one)
   }
}

Context receivers broken with functional interfaces? IntelliJ suggests replacing this

object : MultipleElementDecoder<List<T>> {
        context(ByteArrayReader)
        override fun decode(numberOfElements: Int): List<T> {
            return (1..numberOfElements).map { readUntil('/').decodeNumericRange(block) }
        }
    }

with this lambda:

MultipleElementDecoder { numberOfElements -> (1..numberOfElements).map { readUntil('/').decodeNumericRange(block) } }

But then it complains.. Not even sure what to start searching for in Youtrack.. 😞

I'd like Kotlin to include function return type in the signature.

operator fun ByteBuffer.get(index: Int): Byte = ..
operator fun ByteBuffer.get(index: Int): Int = ..

Swift does that and it's great and the JVM underneath does include the function return type in the signature

Is there any youtrack issue / keep covering this topic? I find row-types one of the best features for any UI-client development.

Why is the following a warning, and not a compilation error?

private fun String.hashCode() = 42

is there any way to say that all subtypes of a

sealed interface

should be data types?

sealed data interface

could perhaps be a nice addition? I would like to use

copy

with the subtypes.. 🙂 apologies for the low-effort proposal.. just want to get some discussion ✌️

Are there any plans to introduce a non-escaping anotation to disable escaping variables of a lambda?

We should provide the

copy

method in all classes that meet the necessary requirements - not just in data classes. A good use case for that are database entities. They have a lot of attributes, and if you model the entities as immutable (which I like to do), you really need to define them as data classes just to get the copy method. But since database tables can have cyclical references, you then need to remember to override hashcode, equals and toString to get back to default behavior. Otherwise you will run into stack overflow errors at runtime. That kind of sucks, when all I ever needed was the damn copy method!

It would be really great to have something like takeUnless which allows you to include the element that fails the predicate:

Iterable<T>.takeUntil(pred: (T) -> Boolean)

or else, to make semantics more explicit, let’s add an optional parameter to takeUnless:

list.takeUnless(includeBreakingElement = true) { … }

or how about this:

list.takeUntilIncluding { … }

to that one we could also add an optional parameter indicating what should happen if no element matches. Callers could either want the entire list/stream returned, or an empty list (not possible for streams/sequences).

Is there any reason why this works: (implementing a functional interface by delegation)

object ColorEncoder : Encoder<Color> by { Encoder { appendable, t -> appendable.appendColor(t) }}()

But inlining the lambda body to this doesnt:

object ColorEncoder : Encoder<Color> by Encoder { appendable, t -> appendable.appendColor(t) }

(I get that we can use a val instead, but would like to use objects to keep things consistent)

Proposal to add

zipWithNull

(as seen on #advent-of-code)

fun <T, R> Iterable<T>.zipWithNull(other: Iterable<R>): List<Pair<T?, R?>> = buildList {
  val first = this@zipWithNull.iterator()
  val second = other.iterator()
  while (first.hasNext() || second.hasNext()) {
    val left = if (first.hasNext()) first.next() else null
    val right = if (second.hasNext()) second.next() else null
    add(left to right)
  }
}

AdventOfCode reminded me of functionality I have wanted in my enterprise software: Multiranges. Or at least the concept of having ranges with functionality for combining them. I want to be able to do Range.overlap(range: Range) and get a new range with just the part that overlaps. Or a multirange that can collect ranges and return the minimal multirange that contains all ranges. e.g.

1..3 + 2..4 + 6..8 = Multirange(1..4, 6..8)

The two biggest missing pieces of Kotlin now are Union Types and Pattern Matching.

Currying?

is there a way to assume from a generic that it's a data class type therefore it has the

copy

method in place?

Does anyone know if there’s any plans yet for kotlin to introduce a type of value class (i know that keyword exists, but it’s for a single value inline class) that’s kind of like a data class, but without the backward compatibliity issues? Ideally it would follow the same rules (must have at least 1 val/var in the constructor, etc…) but generate only toStrings, equals and hashCode. And more importantly NOT generate the

copy

and destructuring functions which can cause backward compatibility issues in libraries. I was pointed to the https://github.com/drewhamilton/Poko library by someone, but i’m reluctant to use compiler plugins if i don’t have to, due to the current lack of a stable api which leads these plugins to have to adapter to the ever evolving plugin api.

is there already a ticket about negating infix calls at the function name rather than at the receiver? ie,

NavInput._DpadLeft !_isTest readMode

Any reason why:

fun interface Foo { ... }
// this works:
data class Baz(val foo: Foo)
val baz = Baz({ ... })
// whereas this doesn't...
fun baz(foo: Foo = { ... })
// it needs to be:
fun baz(foo: Foo = Foo { })

why doesn't the compiler infer Foo as the lambda type in a default value of a function declaration?

is there any effort to generate DSL for the data class

copy

method?

data class Foo(val bar: String)

val foo = Foo("bar")
foo.copy(bar = "bar1") // current

// could be this:
foo.copy {
   bar = "bar1"
}

This message was deleted.

the ability to typealias extension on sealed subtypes

sealed interface Range<T : Comparable<T>>{
   interface BoundedLeft<T : Comparable<T>> : Range<T>
}
val range: Range.BoundedLeft<LocalDate>
typealias DateRange = Range<LocalDate>

although the above statement is how we like to use it, the bottom two lines can't work:

val daterange: DateRange.BoundedLeft (Unresolved reference: BoundedLeft)
typealias DateRange.BoundedLeft = Range.BoundedLeft<LocalDate> (Redeclaration: DateRange)