A modern programming language that makes developers happier.

kotlinlang

set the channel description: Dedicated to all the beginners in kotlin or new in kotlin.

set the channel description: Dedicated to all the beginners in kotlin or new in kotlin.Here you can ask and discuss anything related to kotlin programing language.

set the channel topic: Let's Discuss Kotlin

We are looking at <https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-list/sub-list.html|subList> on a collection. The doc talks about structural changes:
&gt; "The returned list is backed by this list, so non-structural changes in the returned list are reflected in this list, and vice-versa.". 
What does a structural change mean?
I'm assuming it means adding or removing elements from the list. Is that true?

I believe that means if the data within the sublist is changed, the original list is updated as well, unless you’re moving variables. That’s how I would imagine it, but don’t quote me on it

On a mutable list a subList returns a MutableList. Can I add (and remove) elements to that? Or does that lead to undefined behaviour?

I’m not sure to be honest, you can try playing around with it and seeing what happens. Unfortunately there’s not good documentation on it, but it’s a simple enough thing to test with a few lines of code

It does work. If you add an element the underlying list will also contain the element.

However, _if_ this is undefined behavior then there is no guarantee this will work in future releases.

Recieve param no used but is needed.png

Not a beginner but i found something maybe strange. The receive parameter T is marked unused here, but it is required

It should be like `this::class.java` at the moment you are referencing T but not receiver i.e `T.logger.`

if i define a function on a context receiver: `context(Interface)`, should i be able to call that function within a member of a class that implements that interface (`class A : Interface {...}`)?

yeah that should work, polymorphism states that A *is* Interface.

here I wrote some test code for you to play with


```
fun main() {
  
    
    with (FOO()) {
        with (POO()) {
            test()
        }
    }

}

class POO : BAR {
  override fun bar() {
      woo()
  }
}

class FOO {
    fun foo() {}
}

interface BAR {
    fun bar()
}

context(BAR)
fun woo() { print("woooo")}

context(FOO, BAR)
fun test() {
    foo()
    bar()
    print("test")
}```

notice woo() is in context BAR but can be called in POO which implements BAR

Is it possible to flag a property of function deprecated for public use while keeping private (or internal) use legit?
(say, in few months, I'll replace default public visibility by `private`)

Have you looked at the hidden deprecation level? It is stronger than a warning but the code will still compile. If you have a public interface or some layer in between your private and public use cases you could just deprecated in that layer as well