Hi all, is no one missing inline extensions on functional types? I have found a discussion from 2016! And a youtrack issue form 2018 but could not find any activity around it. Sounds almost closer to a bug then a feature request: https://discuss.kotlinlang.org/t/inline-receivers/2084 https://youtrack.jetbrains.com/issue/KT-5837 Additionally,

suspend

-edness is not inferred on functional receivers at call site.

would it break a bunch of stuff to allow destructing like this:

fun foo((x, y): Pair<Int, Int>) = // whatever

do i need any contracts to emulate

if (!buf.hasRemaining() || read == -1) createWriteNode(buf.flip()) else null

with

infix operator fun <T> Boolean.rem(s: T) = { s }.takeIf { this }?.invoke()
...
            (!buf.hasRemaining() || read == -1) % createWriteNode(buf.flip())

to guarantee that

s

doesn't fire before comparison? i actually prefer

inline val <reified T> T.`⟲`  get() = { this }
inline infix operator fun <reified T> Boolean.rem(s: T) = s.`⟲`.takeIf { this }?.invoke()

as the style matches the idioms i use in in prior art but i just don't quite find the langauge lawyer parts i need to trust bytebuffer ops to this one, it has worked for more mundane ternary targets leading up to this but bytebuffers have effects

c#10 adds static abstracts to interface. in kotlin that would be like declaring functions or members in an interface that implementing classes must define in their companion object. that's a pretty cool feature for writing mathematical libraries or DSLs, imo. it's runtime, however, so I expect JB is not keen to add something like that to kotlin. i'd always considered kotlin to be a feature superset of c#, but as of a few version ago, that's not the case.

Can we imagine Kotlin code being preemptively partially compiled with a low process/thread priority, so when we actually want to run, very few code remains to be compiled?

Why it is not possible to not erase type by generics - because of JVM limitation? Currently I am not able to do this - as two LisenerBases collide as their types are erased at runtime.

class Player : Listener<State> by ListenerBase<State>, Listener<Source> by ListenerBase<Source>

But why? Specified generic is a separate type to me. Why cannot I reuse one class for aggregation?

Not sure if this is the best place to post this, but is there a source for values for

apiVersion

and

languageVersion

like a maven artifact or Github Release? I'm trying to set up a CI matrix to make sure we're compatible with the latest versions, but would like to avoid hardcoding them and somehow programatically fetch the latest ones where possible

hello 👋  , im hoping to get traction on this post , thanks in advance for your time and consideration.

I'm kind of frustrated for having to use a custom lib for unsigned because inline classes cannot extend other classes (ie

Number

). So I was thinking, maybe we can have inline classes exposes/extends/delegates specific interfaces/classes from the underlying value.. something like

inline class UInt(val i: Int) : Number by i

Me and another dude (ArcheCraft) are revamping a kotlin glm port (multiplatform plus code generation). While we are at it, there is always this problem about allocations which bothers me (at least till we get valhalla)

val a = Vec3()
val b = (a + 1) / 2

a + 1

will generate another

Vec3

and so will

/ 2

. This normally isn't the end of the world, but in specific situations, such as real time 3d graphics, embedded devices, hotspots, etc etc this may be an issue. Googling around for ideas, I saw that also @Aleksei Dievskii in its viktor had this burden to deal with. So I was wondering if there might be some solution involving some new language paradigms or features..

what about implicit parameters for multi-arguments lambdas? ie:

it0, it1,..

Hello team. I am working on some papers for school and I wanted to get some clarification on this portion of the Kotlin Language Specification:

Kotlin Language Specification is still in progress and has experimental stability level, meaning no compatibility should be expected between even incremental releases, any functionality can be added, removed or changed without warning.

https://kotlinlang.org/spec/introduction.html#compatibility What does this refer to when talking about being in experimental stability? Is this referring to the document itself?

Hi All, consider the following function signature:

inline fun <reified T: Fragment> replaceFragment(
        name: String = T::class.java.name
    )

Why do I need

inline refied

in the signature? I do understand that T.class.java can not work on an erased type but, If I understand correctly, kotlin would insert the default parameters at call site where the type information is readily available. If I am not mistaken in my assumptions, I propose to lift the restriction on generic types for when they are used in default parameter definitions.

[not sure this is the right channel so let me know if there's a better place] I'm trying context receivers and tried to write an alternative "scoping" function but it didn't work:

class Logging {
  val logger = java.util.logging.Logger.getLogger("test")
}

context(Logging)
fun hello() {
  <http://logger.info|logger.info>("Hello")
}

fun <C, R> within(ctx: C, call: context(C) () -> R): R = call(ctx)

fun main() {
  within(Logging()) {
    hello() // Error: No required context receiver found: Cxt { context(Logging) public fun hello(): kotlin.Unit defined [...]
  }
}

Is this supposed to be this way or it's just something not yet implemented in the prototype version?

I'd like some way to split long single-ling Strings in my source file, but have the compiled code be a single String. As I understand it, the options to split a long String like this now are all lacking in one or more ways, meaning that in practice these long Strings just remain long Strings in the source, despite exceeding max line length lint rules: • use a

buildString

block: overkill for this scenario, and while performant, still some runtime overhead • String concatenation: not visually appealing, runtime overhead • some combination of raw strings with

trimMargin

and removing newlines: runtime overhead Thoughts?

does c#'s pattern matching they intrigue the kotlin team at all?

Are there language devs here? I have a burning question, I really like kotlin but this point is one that frustrates me a lot and I just wanted to know the reasoning behind the decision. Why are kotlin ranges inclusive on both ends instead of being [start, end) like most languages (that I've seen). I find this really hard to reason about, and I know that's on me xD but I still want to know what lead to this decision (note, I know about

until

but the toString implementation prints as inclusive of both ends)

Why are local property references not allowed, when local delegated properties are a thing, AND they receive a property instance in their

getValue

and

setValue

methods? Is it to do with how regular local properties have a weird "backing field" and so supporting that can get muddy when it comes to cross-thread references and all? or is there another piece to the puzzle? And if that's the case, why not allow references to local delegated properties? After all, their mechanics are near-identical to normal delegated properties.

Was making `is`/`as` functions instead of language features ever considered? (similar to how Java casting went that direction, and how there's a general preference for not introducing language features when it can be done another way. Or even making them soft keywords so functions could be introduced I could see it being done like this, with contracts to enable smart casting/etc:

x.is<String>()
x.isNot<String>()
x.as<String>()
x.asOrNull<String>()

For one I think it would make chaining nicer. There are definitely times when I do

.let { it as String }

on its own line in the middle of a big chain of calls, and was tempted to wrote my own

fun <T> Any?.as(): T

but got dissuaded when I need to write `.`as`<...>()`. Mostly just a curiosity though :)

Is it possible to allow

@HidesMembers

in the future to work for more functions? And specifically, because I prototyped this in Kotlin 1.4 I think, can the resolution order for

@HidesMembers

be fixed to work for member extension functions (I think when I tried to get it to work

HidesMembers

only works for plain extension funs)? My use case is changing the behavior of functions like

toString

. Consider the fp-style Show:

interface Show<T> {
    @HidesMembers
    fun T.toString(): String
}

object IntShow: Show<Int> {
    @HidesMembers
    override fun Int.toString() = "$this is an Integer"
}
// usage
with(IntShow){
    println(5.toString())
}

but this can work for overriding any member function to explicitly change its behavior whenever a receiver is in context. I would wager that this isn't surprising to the user of a library because they explicitly opt-in by bringing a receiver in scope. Could this ever be a kotlin feature or am I dreaming too much lol?

Could compile-time operations on raw strings ever be allowed for constants - e.g.

const val rawString = """
    this
    is
    a
    raw string
""".trimIndent()

is currently an error. But could it be changed at compile time to the equivalent of

const val rawString = "this\nis\na\nraw string"

Context receivers workaround to allow for type parameters inside lambdas. (Workaround for KT-51243) I should've shared this ages ago, but I was trying to figure out how to explain the way that it works, and I've given up honestly, so here it goes: It looks like something is broken with context receivers not being visible in lambdas if those contexts are generic type parameters. What's weirder is, after some testing, if you utilise the type parameter in any other part of the lambda signature e.g. a normal parameter, then all the context receivers up to and including that generic type parameter will be visible inside a lambda. This general structure here just has the type of the last generic context as the

TypeWrapper

that is passed to the lambda, effectively making all the receivers before it visible.

inline fun <A, B, C, R> withContexts(a: A, b: B, c: C, block: context(A, B, C) (TypeWrapper<C>) -> R): R {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    return block(a, b, c, TypeWrapper.IMPL)
} 
sealed interface TypeWrapper<out A> {
    object IMPL: TypeWrapper<Nothing>
}

(Psst: here's a function to generate those up to an arity of 25):

fun generateDeclarations(index: Int): String {
    val alphabet = "BCDEFGHIJKLMNOPQSTUVWXYZ"
    val letters = ("A" + alphabet.take(index)).toList()
    val lastType = letters.last()
    val types = letters.joinToString(", ")
    val receivers = letters.joinToString(", ") { it.lowercase() }
    val parameters = letters.joinToString(", ") { "${it.lowercase()}: $it" }

    @Language("kotlin") val codeTemplate = """
        inline fun <$types, R> withContexts($parameters, block: context($types) (TypeWrapper<$lastType>) -> R): R {
            contract {
                callsInPlace(block, InvocationKind.EXACTLY_ONCE)
            }
            return block($receivers, TypeWrapper.IMPL)
        }
    """.trimIndent()
    return codeTemplate
}

Extension functions on classes that have class context receivers (e.g.

context(Hello, World) class Foo { ... }

) should be able to access those class's receivers. Additionally, maybe the same behaviour can be applied to a context receiver that is a context class. Lemme explain with an example:

class Hello { fun hello(name: string) = TODO()
class World { val value = 42 )

context(Hello, World) class Foo

fun Foo.fooExtender() {
    // I should be able to call this with no issues
    hello(value)
}

context(Foo) fun doSomethingInFooContext() {
    // I should be able to call this with no issues
    hello(value)
}

If the behavior for the

doSomethingInFooContext

is too surprising, maybe we can have a special keyword for it (i.e.

propagate

or something), or, we can only allow Hello and World to propagate through if Foo is available as a normal receiver and not a context one (IMO this is surprising and unintuitive). Something to think about though is that if this is implemented, it'll be best to treat those class contexts as a heirarchy level above the other contexts (e.g. resolution order should be Foo's contexts are "weaker" than foo itself) and I recall that such heirarichal behaviour was considered unintuitive before, but it seems like it could be a necessary evil if we want class contexts to work intuitively

Hi folks, I test the Context Receivers and I notice that Generic types are acceptable but is not working as intended, there is any issue tracking generic types in Context Receivers ?

Hi! trying the context receivers, i got this error

object Dependency {
    val dep1: String = "1"
}

val lambda: context(Dependency)() -> Unit = {
    dep1
}

Compose (1.2.0-alpha08) + Context Receiver (1.6.20) =

java.lang.Exception: IR lowering failed at: ….

we will have to wait a little longer hehe

Hi, simple question, what will be the version after 1.9 ? 2.0 or 1.10 ?

Not sure if this is a bug with context receivers or just type inference not being strong enough. It seems as though the choice of a specific context receiver doesn't influence the choice of another context receiver when it comes to type parameters. Reproducer (The code is absurd but I have a legitimate use case that doesn't surround collections):

// Implementation really doesn't matter, neither do the specific collections.
context(Map<K, V>, Set<V>)
fun <K, V> K.checkInclusion(): Boolean = this@Map[this] in this@Set // Check if our key K has a value which is a member of a set of accepted values

context(Set<Int>, Set<String>, Map<List<String>, String>, Map<List<Int>, Int>) // The last receiver is not needed to reproduce
fun reproducer(){
    listOf("hello", "world").checkInclusion() // Error: Multiple arguments applicable for context receiver
}

However, if I just let IntelliJ insert explicit type arguments based on what it has inferred, everything compiles successfully:

listOf("hello", "world").checkInclusion<List<String>, String>()

IntelliJ even greys out the type arguments, saying that they're redundant. Is this a bug? Should I file this?

why? it's a constant