Alejandro Serrano

> As for the first issue, I can't think of any situation where this new syntax would create a problem because I don't think Kotlin has any expression and type...

Let me try to spell out some of the concerns and how important they were in the current design. ☣️ **Full backward compatibility**: every program which currently compiles should keep...

> Bringing constants or enums into the scope seems natural. However, bringing functions is quite surprising. Note that there's a fine line into what counts as function here and what...

Let me reiterate that Swift had that syntax from the beginning, so whatever the chose back then has been stable. We have a different starting point, with lots of code...

> I just tested with Kotlin 1.9.23 and confirmed that the current variable resolution is opposite to the way it would behave with this KEEP. Please be careful, as there's...

> With 3 files, I see the same behavior Sorry, my bad, I said "three files", but I meant "three packages". But yes, indeed imported elements have a high priority....

I've taken some time to compare Swift's and Kotlin's grammar, to figure out whether and how `.value` syntax could be accommodated. --- Swift defines [implicit member expressions](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/expressions#Implicit-Member-Expression) using the following...

One general rule we try to follow is that developers can easily track where some of the names are coming from. In this case, we do so by propagating only...

To me, I think the proponents of the `.value` syntax need some more convincing arguments that the restrictions and potential for error (for example, when you try to use it...

> What if there exists a framework that behaves differently based on whether the annotation is specified on the constructor parameter or on both the constructor parameter and fields. Would...