https://kotlinlang.org logo
Join the conversationJoin Slack
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by Linen
language-evolution
  • g

    George

    06/13/2022, 5:50 PM
    Hi folks, a general question: is there any doc about why the kotlin-team decided to make kotlin classes by default final? Im looking something like a KEEP. I searched in the Keep, docs, and now im looking in the spec but i cant find any detailed explanation like in the keeps. Does anyone know if it even exists something similar? Thanks in advance for any answer 🙂
    e
    m
    i
    • 4
    • 6
  • n

    Nathan Bedell

    06/23/2022, 3:02 PM
    Does anyone know why the new underscore type operator in Kotlin 1.7 seems to not be working for me? I'm using the Android Kotlin gradle plugin with Kotlin 1.7, and wherever I put "_" for a type argument, I just get "Unresolved reference: _". Is this a feature that needs to be explicitly opted-in to? From the 1.7 feature update it sounded like this should work be default. Even a simple example like mapOf<Int, _>(2 to 3) doesn't work for me.
    m
    d
    • 3
    • 3
  • m

    Mikhail

    06/28/2022, 9:35 PM
    // in kotlin you can
    suspend fun hi() {
        suspend fun thing() {
        }
     
        thing()
    }
    
    // you can
    suspend fun hi() {
        val thing: suspend () -> Unit = {
        }
    
        thing()
    }
    
    // you can
    fun hi() {
        val thing = fun() {
        }
      
        thing()
    }
    
    // but you CAN'T
    suspend fun hi() {
        val thing = suspend fun() {
        }
    
        thing()
    }
    any specific reason?
    🤔 2
    e
    i
    • 3
    • 4
  • a

    Ayfri

    07/07/2022, 10:00 PM
    Does Kotlin 1.7.10 is out ? There is this on the website :
    m
    e
    +2
    • 5
    • 8
  • y

    Youssef Shoaib [MOD]

    07/13/2022, 10:33 PM
    Does
    @OverloadResolutionByLambdaReturnType
    not cover the case where one of the return types is a subtype of the other? For instance, this surprisingly fails (playground):
    @OptIn(kotlin.experimental.ExperimentalTypeInference::class)
    @OverloadResolutionByLambdaReturnType 
    inline fun printIf(condition: Boolean, message: () -> Any?) { 
        if(condition) println(message()) 
    }
    inline fun printIf(condition: Boolean, message: () -> Int) { 
        if(condition) println(message()) 
    }
    fun main() {
        printIf(true) { 42 }
        printIf(false) { "hello world" } // Type mismatch: inferred type is String but Int was expected
    }
    This can obv be used to avoid boxing primitives like Int when unneeded. I know the cost of boxing is marginal, but in a tight loop it can be detrimental.
    • 1
    • 1
  • b

    Brendan Campbell-hartzell

    07/14/2022, 5:56 PM
    The idea of compiler plugins has been floating around for a while now, and 1.7.0 has started to make some strides in that direction. Is the plan for compiler plugins to eventually work similarly to Rust's macros? Effectively allowing the kotlin community to build their own kotlin features and syntax? Or am I thinking about this incorrectly?
    d
    • 2
    • 1
  • m

    Mikhail

    07/15/2022, 1:24 PM
    why is it applied to tests?
    j
    d
    k
    • 4
    • 14
  • k

    Klitos Kyriacou

    07/22/2022, 2:44 PM
    This case is not considered exhaustive and results in compilation error:
    when (Pair(bool1, bool2) {
        Pair(false, false) -> {...}
        Pair(false, true) -> {...}
        Pair(true, false) -> {...}
        Pair(true, true) -> {...}
    }
    Is it just because it's too difficult for the compiler to figure out that it is in fact exhaustive?
    d
    c
    m
    • 4
    • 3
  • k

    Klitos Kyriacou

    07/25/2022, 8:11 AM
    Any idea why
    then
    is an infix function but
    thenBy
    isn't?
    🤔 2
    e
    • 2
    • 3
  • h

    hfhbd

    09/07/2022, 7:43 AM
    What about adding a contract to delegated properties, which allows smartcast with the provided value by ensuring to always provide the same value? Use case: kotlinx-cli parser or Compose State. Both libraries ensure the provided value is stable and does not change.
    val parser = ArgParser("ejwrapper")
    val jobID by parser.option(ArgType.String)
    parser.parse(args) // No changes to jobID after parsing
    
    if (jobID != null) {
        val status = getJobStatus(jobID) // smart cast is not possible because jobID has a open or custom getter
    Current workaround is
    !!
    , another variable or
    let
    e
    • 2
    • 2
  • o

    Olli Helenius

    09/30/2022, 8:57 AM
    so no changing the type of a member with copy()? is there an issue i can go vote? 🙂
    h
    k
    a
    • 4
    • 8
  • s

    Sam Stone

    11/04/2022, 2:54 AM
    Wouldn't it be cool (not necessarily simple to implement) to be able to specify the constraints of a function's input and have them checked statically and guaranteed by the compiler, just like it does for null safety? For example, that a number is within a certain range (more so than the fact that the number fits into a Short or Long), or a string isn't empty or matches a regex. Possibly more complex things would be that a list can't be empty, or that the parameters match certain predicates. In some ways this is the logical next step in specifying the constraint that objects can't be null (specifying other constraints). I feel like function bodies would be more focused on what they are actually meant to do, instead of verifying input validity. In some ways this is basically a
    contract
    about the preconditions. There could even be an error message associated with each precondition.
    @Precondition(
        target=a,
        condition=Preconditions.nonNegative(), 
        message="a cannot be negative!"
    )
    @Precondition(
        target=a,     condition=Preconditions.lessThan(b), 
        message="a must be less than b!"
    )
    fun foo(a: Int, b: Int)
    Could also apply to variables:
    @Invariant(condition=Preconditions.nonNegative())
    @Invariant(condition=Preconditions.inRange(1..5)
    var x: Int
    Could possibly do
    @Invariant(conditions=[...])
    s
    e
    • 3
    • 2
  • d

    David Bieregger

    11/07/2022, 12:31 PM
    Why is this syntax for multiple context receivers:
    context(Logging, Application)
    fun hello() {
      <http://logger.info|logger.info>("Hello " + applicationName)
    }
    Prefered over this:
    fun (Logging, Application).hello() {
      <http://logger.info|logger.info>("Hello " + applicationName)
    }
    In my opinion the second one is more readable and makes intuitively more sense when you know how to do one context receiver just put braces around. I'm sure that considerations have been made here, but I can't imagine one real advatage of the first code example over the second one
    d
    b
    e
    • 4
    • 7
  • j

    Julia Samól

    11/09/2022, 6:06 PM
    Is there any plan to improve the exception handling in the nearest future, i.e. enforcing or at least suggesting that there might be exceptions worth handling at compile-time? I know this topic has been discussed multiple times already, I’ve seen a proposal where someone suggested an approach similar to Swift’s, I’ve also seen an apparently still ongoing debate that started as a feature request for checked exceptions but which eventually has evolved to be a discussion on exception handling in Kotlin in general. I’m bringing this up again here because, well, I’m simply not happy with the compiler not warning about exceptions in any way. Don’t get me wrong, I’m not opting for checked exceptions here. I do agree that Java’s way is far from ideal, but I just also happen to think that what Kotlin does right now, allowing any exception to be left unhandled and potentially crash the application, isn’t good either. Especially that it comes from a language whose one of the core features is compile-time null safety which aims to help people avoid crashing their apps partially because of an oversight. And of course, I do understand that it’s a complex issue, many people have different opinions on it, probably some won’t even agree with what I’ve written above, but, regardless of these opinions, exceptions are part of the language and could use better support. Maybe there could be a compiler flag, similar to what we got for the explicit API mode, which would allow developers to tweak the compiler into helping them: • not to forget to annotate their throwing functions with
    @Throws
    • not to overlook functions annotated with
    @Throws
    and handle them properly?
    e
    c
    a
    • 4
    • 18
  • s

    Sam Stone

    11/25/2022, 4:48 AM
    Should this be part of the language?
    val Any.field
            get() = when (this) { //these classes don't inherit a common ancestor that has the getField() method, so we need to parse them out into distinct classes
                is Class1 -> field
                is Class2 -> field
                is Class3 -> field
                ...
                else -> null? throw error?
            }
    A useful feature that would help this case is if I could specify that a function can only be called on certain types, similar to
    where
    , so that the compiler knows that it is at least one of those classes, and can find the corresponding function or field. At the very least, it would write this out for me.
    w
    r
    k
    • 4
    • 5
  • r

    Rohan Maity

    11/27/2022, 5:06 PM
    [Discussion item] Hi, I came across this article Expression problem and its solutions, in this author discusses various languages and how they fall short to solve the expression problem because of lack tools. Author further went and told how Closure though its language features it solves the expression problem A brief explanation on expression problem Imagine that we have a set of data types and a set of operations that act on these types. Sometimes we need to add more operations and make sure they work properly on all types; sometimes we need to add more types and make sure all operations work properly on them. Sometimes, however, we need to add both - and herein lies the problem. Most of the mainstream programming languages don't provide good tools to add both new types and new operations to an existing system without having to change existing code. This is called the "expression problem". Now the crux of the Clojure language to solve the expression problem was open methods i.e you can add methods to the class without changing the source code Here is the Clojure example by author: link After going through this, it occurred to me, the extension functions of kotlin kinda does the almost same job. It allow us to add function to the already existing class without changing its source code in a way (I am excluding the part where in bytecode it creates a static function) Here is my example for kotlin which I think solves the expression problem (gist link)
    // Initially I have an interface Expr (just like in Java) and have two classes  (Constant
    // and BinaryPlus) implement that interface 
    
    
    interface Exp {
        fun eval(): Double
    }
    
    class Constant(val value:Double): Exp {
        override fun eval(): Double = value
    }
    
    class BinaryPlus(val lhs: Exp, val rhs: Exp): Exp {
        override fun eval(): Double {
            return lhs.eval() + rhs.eval()
        }
    }
    
    
    /**
    * Here, I added the stringify() method (which is a tool or operation) to the interface Expr,
    * without touching the interface and classes which are implementing it.
    */
    
    fun Exp.stringify() : String {
        return when(this) {
            is Constant -> value.toString()
            is BinaryPlus -> "${lhs.stringify()} + ${rhs.stringify()}"
            else -> ""
        }
    }
    
    // Here is how, I can use it
    
    fun main() {
        println(BinaryPlus(Constant(4.0), Constant(9.0)).stringify())
    }
    
    /**
    * Now in object oriented languages, adding types is easier 
    * and functional languages adding tools(or operations) is easier 
    * but since kotlin can act as functional and object oriented and with my above given example.
    * I think extension function solves the expression problem for kotlin.
    */
    r
    f
    d
    • 4
    • 12
  • r

    Ruckus

    12/08/2022, 3:39 PM
    Is there any information/update on context receivers? The preview was added back in 1.6.20, and there was a flurry of discussion, as well as several issues reported, and I've seen radio silence on that front since. Am I just not following the right sources to get information, or is there indeed no information to be had?
    e
    • 2
    • 2
  • k

    Kroppeb

    12/09/2022, 4:53 PM
    Is there a way I can provide a certain context receiver at the file level?
    e
    • 2
    • 7
  • k

    Kroppeb

    12/09/2022, 4:54 PM
    also, is
    context(InternalAddOp<T>, InternalAddOp<R>)
    prohibited, cause in theory they could have a subtype relation between them, or is that an error?
    s
    y
    • 3
    • 11
  • k

    Kevin Del Castillo

    12/09/2022, 7:23 PM
    I was reading this blog about Dart 3 and their roadmap to sound null safety and found something interesting mentioned about Kotlin:
    Kotlin has several unsound exceptions, in part due to its goal to interoperate with Java. As you can see in this Kotlin example, generic types can trigger cases where null values can flow into a list declared as holding non-null elements.
    I understand why Java libraries can sometimes be troublesome (
    T!
    ), but I'm a bit confused about the generic types example they're giving, this is the offending code:
    private fun <E> List<E>.addAnything(element: E) {
        if (this is MutableList<E>) { this.add(element) }
    }
    
    fun main() {
        // A list of non-null Ints.
        var myList : List<Int> = arrayListOf(1, 2, 42)
    
        // Add a null.
        myList.addAnything(null)
        
        // Add a non-number.
        myList.addAnything("This is not even a number")
    
        // Print resulting list, not matching `List<Int>`.
        print(myList);
    }
    Which prints:
    [1, 2, 42, null, This is not even a number]
    Why is this happening? My first guess is that the
    if
    in
    addAnything
    is true because of type-erasure, is this correct?
    m
    p
    +2
    • 5
    • 5
  • p

    PHondogo

    12/18/2022, 7:07 PM
    Hello! Is there any planning to include possibility to pass function argument by ref?
    v
    j
    +2
    • 5
    • 7
  • v

    vngantk

    12/23/2022, 10:11 PM
    What do you mean by passing function argument by ref?
    p
    • 2
    • 3
  • k

    Klitos Kyriacou

    01/04/2023, 3:42 PM
    Is there a reason the only operators allowed in
    when (expr) { ... }
    blocks are just the four specific operators
    is
    ,
    !is
    ,
    in
    and
    !in
    ? It seems quite arbitrary to limit the allowed operators instead of saying you can have any binary operator with just its right-hand side (for example,
    when (temperature) { < 5.5 -> ... }
    e
    p
    • 3
    • 3
  • n

    Nathan Bedell

    01/27/2023, 11:15 PM
    Edit: Ignore this. Don't think I can delete this now, but just saw someone else asking the same question above and the answer. Just really surprised I wasn't able to find an answer to this googling. Apologies if this has already been posted, or this is not the right place, but I can't seem to find any information about this online, so I thought I'd ask here. It looks like context receivers were removed from the roadmap. Why? Is this being dropped entirely, or is the focus just on other things right now?
    d
    e
    • 3
    • 2
  • d

    Dron Bhattacharya

    02/16/2023, 10:11 AM
    IMPORTANT FEEDBACK Coming from a javascript and python background, I am facing great difficulty in using Kotlin. The same for my friends too. For getting good at Kotlin, the environment is kind of like "You must know java or c++ like language if you want to learn Kotlin". Also, I love using the terminal for most of my work. But Kotlin tries to force you to use IntelliJ. I want to mention that I love the language really and I don't want to leave this language behind. But it has been more than a month or two, and I still cannot figure out how to create an executable using Kotlin. And also, I and sick of using IntelliJ. No offense, but using the IDE for a simple program is not worth it. For this, I don't even feel like writing some coding with Kotlin in my daily life. But I am still not leaving it, as I love the language at its core. So, can anyone help me with this? I can be thinking in the wrong way; in which case guide me in the right direction.
    j
    m
    +3
    • 6
    • 12
  • m

    mbonnin

    02/21/2023, 2:54 PM
    Certainly a long shot but are there any discussions about introducing types that are completely erased (not just generics) in Kotlin? A bit like the typescript type system. At built time, all the type checking would happen. At run time the objects could be some
    Map
    -like type I guess and property accesses would be cast to the build-time type (and assert if wrong). Does that make any sense?
    e
    c
    +3
    • 6
    • 27
  • m

    Michael de Kaste

    03/01/2023, 2:16 PM
    I can't find a KEEP for it, but I'm guessing people have been requesting
    filterKeysIsInstance
    and
    filterValueIsInstance
    on a Map? Would like to track its progress if its there.
    m
    e
    • 3
    • 2
  • l

    Luke

    03/01/2023, 9:31 PM
    Would it be possible/interesting to have the compiler generate the negation of boolean variables and functions that return booleans? For example, let's say this is defined:
    val String.isValidUrl: Boolean get() = TODO()
    fun areValidCredentials(email: String, password: String): Boolean = TODO()
    Then, could the compiler generate:
    val String.isNotValidUrl: Boolean inline get() = !isValidUrl
    fun areNotValidCredentials(email: String, password: String): Boolean = !areValidCredentials(email, password)
    The name could be changed via annotation, or by default the compiler wouldn't do anything but adding an annotation with an optional name could generate the negations..? I feel it would make code more readable than having the
    !
    before or
    .not()
    after. The standard library already has some negated function such as List.isNotEmpty, so I feel Kotlin could improve by generalizing this trend.
    e
    d
    +3
    • 6
    • 9
  • s

    Sam Stone

    03/06/2023, 12:09 AM
    Should there be a way to make all interface methods optional to implement? Take
    android.text.TextWatcher
    . I am not interested in
    beforeTextChanged()
    and
    onTextChanged()
    , only
    afterTextChanged()
    . Should the compiler assume (or can I inform it) that I will implement it like this?
    object : TextWatcher {
                override fun beforeTextChanged(...) {}
                override fun onTextChanged(...) {}
                override fun afterTextChanged(...) {
                    ...
                }
            }
    l
    r
    y
    • 4
    • 11
  • d

    Dirk Hoffmann

    03/13/2023, 4:13 PM
    HI, while playing around with context receivers
    context(someInstance, someInterface)
    I just realized, that if you want to use context receiver declaration on
    override fun xyz(...)
    on
    interface
    methods, then you have to have the context declaration on BOTH, the interface fun definition AND the implementing class fun (correct??). That is ok by itself ... but the compile time error message for this is 2-pages long and really really cryptic with no hint what might be the problem whatsoever ... don't know if this is the correct channel, but I would love to see a bit more "readable and usefull" compiler error for that case.
    e
    • 2
    • 6
Powered by Linen
Title
d

Dirk Hoffmann

03/13/2023, 4:13 PM
HI, while playing around with context receivers
context(someInstance, someInterface)
I just realized, that if you want to use context receiver declaration on
override fun xyz(...)
on
interface
methods, then you have to have the context declaration on BOTH, the interface fun definition AND the implementing class fun (correct??). That is ok by itself ... but the compile time error message for this is 2-pages long and really really cryptic with no hint what might be the problem whatsoever ... don't know if this is the correct channel, but I would love to see a bit more "readable and usefull" compiler error for that case.
e

elizarov

03/14/2023, 12:21 PM
Yes. You have to use it on both. Compiler currently crashes if there is a mismatch, e.g. https://youtrack.jetbrains.com/issue/KT-51474
d

Dirk Hoffmann

03/17/2023, 10:21 PM
@elizarov yes, that's ok ... but are there any plans (e.g. included in the "outcomes" of your linked ticket) to present the user a more meaningful error message? It took me half a day to decrypt the stacktrace and to find the root cause in the missing context() on the interface function.
BTW, right now I have some new finding, and am not sure if I should file a bug for this, maybe you can have a look at it upfront: working version:
Untitled.cpp
Failing version:
Untitled.cpp
diff:
context() is Failing when the function is implemented via a delegated interface.
View count: 7