https://kotlinlang.org logo
Join Slack
Powered by
# language-evolution
  • c

    CLOVIS

    05/27/2025, 7:14 PM
    Context parameters are arriving in experimental mode in 2.2. Is there a binary compatibility guarantee from 2.2 to the future, even if the syntax and limitations are still subject to change (like for contracts)?
    👀 1
    e
    • 2
    • 1
  • e

    Edoardo Luppi

    05/29/2025, 9:18 AM
    Is there an issue for default types for generic type parameters? And, has this ever been considered as a language enhancement?
    s
    m
    • 3
    • 11
  • c

    CLOVIS

    05/29/2025, 4:03 PM
    Copy code
    fun foo(range: ClosedRange<*>) {}
    fun foo(range: OpenEndRange<*>) {}
    
    foo(5..12)
    gets
    Copy code
    Overload resolution ambiguity between candidates
    because
    IntRange
    is both
    ClosedRange
    and
    OpenEndRange
    … It's a shame because the behavior would be exactly the same no matter which one the compiler chose. Is there another solution other than creating a new overload of
    foo
    for
    ByteRange
    ,
    ShortRange
    ,
    IntRange
    and
    LongRange
    , and also all the unsigned ones?
    k
    • 2
    • 4
  • m

    mikhail.zarechenskiy

    06/03/2025, 8:39 AM
    Hey! I’d love to hear your thoughts on the default applicability of annotations. You might’ve heard that we’re planning to slightly adjust how annotations are applied by default. For example, in a class like
    Person(@Email val email: String)
    , the
    @Email
    annotation would be applied to both the constructor parameter and the field, while today it only applies to the parameter. This change seems safe and reasonable, and was originally motivated by KT-19289 At the same time, we’ve been considering a more aggressive default: applying annotations to all applicable targets. For instance, in
    @Anno var x: String
    , the annotation could be applied to the property, backing field, getter, setter parameter, and so on. This is similar to how annotations work for records in Java. Initially, we were cautious about this idea, we thought it might break some frameworks. But based on recent conversations, it seems this concern may not be as serious as we thought. Perhaps we should move toward this broader default after all. So I wonder if you could share your thoughts and any known pitfalls of changing the default. What do you think?
    c
    e
    +6
    • 9
    • 21
  • c

    CLOVIS

    06/05/2025, 12:49 PM
    To clarify the new rich errors proposal, is it planned to add new
    error data object NotFound
    and all
    firstOrNotFound
    ,
    firstOfOrNotFound
    etc variants? The KEEP mentions how the language will change, but I didn't see anything about the changes to the standard library.
    ➕ 1
    m
    • 2
    • 4
  • y

    Youssef Shoaib [MOD]

    06/05/2025, 4:37 PM
    Is there any rough idea of when type outference will be available as a prototype or experimental? I'm wondering how it deals with some complicated examples I have, including existential types.
  • a

    Alejandro Serrano.Mena

    06/06/2025, 9:14 AM
    The public KEEP review for static members and type extensions is now open. We would love to hear your feeback! 🙂 (Feedback and discussion on the proposal happens here, feedback on the text itself happens here)
    👀 3
    ❤️ 1
    k
    • 2
    • 1
  • c

    cketti

    06/06/2025, 12:13 PM
    Hi. I'd like to have a string escape sequence that makes it easier to include astral code points (value greater than 0xFFFF). So I could write e.g.
    "\u{1F995}"
    instead of
    "\uD83E\uDD95"
    or
    "🦕"
    . Granted, often it's preferable to use the last variant. But there are cases where (programming) fonts are missing glyphs or the code point isn't associated with a visible character. In such cases, having to use escapes of the surrogate characters just doesn't make for a great developer experience. Does this sound like something that has a chance of being added to the language? Or would I be wasting my time if I wrote up a KEEP? (I already have a prototype to add support to the compiler.)
    👍 1
    ➕ 1
    c
    y
    +4
    • 7
    • 25
  • e

    Edoardo Luppi

    06/09/2025, 1:46 PM
    Related to KEEPs, there are a couple problems imo with the way Discussions are handled by GitHub. • GitHub displays Issues on the dashboard's Recent Activity, which means they're immediately visible (I don't forget about them) and I can see when they've been updated as they raise up to the top. • GitHub doesn't display the count of open Discussions, and it may look like there are none to someone that's never, or rarely, used them. On the other hand what I like about Discussions is I can order by most upvoted thread. Tho, I don't like that thread upvotes are separated from reactions.
  • y

    Youssef Shoaib [MOD]

    06/11/2025, 2:13 AM
    With Rich Errors, will we have a well-typed
    suspendCoroutineUninterceptedOrReturn
    and
    startCoroutineUninterceptedOrReturn
    ? That'd require making
    COROUTINE_SUSPENDED
    an Error type, which is hard since it's currently an
    enum
    member for serialisation's sake. I imagine, because this is an intrinsic, it doesn't matter much
    ➕ 3
  • j

    jNayden

    06/11/2025, 6:41 AM
    Off topic but Java has a nice history page on wikipedia https://en.wikipedia.org/wiki/Java_version_history is there something similar for kotlin ?
    k
    • 2
    • 4
  • r

    rnett

    06/16/2025, 6:37 AM
    Is there a YouTrack issue or similar thing I can upvote for the
    local
    parameters mentioned in the outference talk? I was not able to find any myself
  • y

    Youssef Shoaib [MOD]

    06/17/2025, 7:37 PM
    Any plans for intersection types? My understanding is that the type system already uses them, no? Are there some rough edges that need to be improved before they can be made denotable? There's a few tricks btw to get them to show up, mostly involving using
    InlineOnly
    .
    c
    • 2
    • 5
  • v

    vngantk

    06/20/2025, 10:22 PM
    Will Kotlin support some form of structural typing on top of its nominal typing? I recently did a lot of Typescript programming, and found its structural typing very versatile and suitable for data-intensive business applications.
    y
    • 2
    • 1
  • g

    Ghasem Shirdel

    06/27/2025, 2:46 PM
    Hi 👋 I have a question regarding rich errors that are expected to be introduced in Kotlin 2.4. Many libraries we use—whether Java-based or Kotlin libraries that don't adopt this feature—still throw exceptions. In those cases, we either need to use runCachingAsError to convert them into a general error class, or manually wrap each exception from those libraries ourselves. Is there any plugin currently in development that can automatically generate Error classes, Error objects, or even type aliases from existing exceptions? Since Java relies on exception inheritance, it would be great to have a way to map that structure to Kotlin's error model.
    🦠 1
  • r

    Rafael Diaz

    06/29/2025, 9:36 PM
    Hi! I was wondering how other people handle sharing internal code across modules without leaking it to the public API. I'm currently working on a Gradle plugin, and I have constants that are shared between multiple modules but I'd rather not have exposed to the end user. I wish there was a way to have something akin to the
    internal
    modifier but with the possibility to scope to multiple modules. I figure it's probably a niche request so I was wondering how other people have handled the situation.
    m
    e
    +2
    • 5
    • 6
  • c

    CLOVIS

    07/17/2025, 1:48 PM
    I'm wondering why
    companion data object
    is forbidden?
    j
    • 2
    • 1
  • e

    eygraber

    07/21/2025, 2:05 AM
    Was

    type-outference ▾

    sneakily the most impactful talk at KotlinConf?
  • c

    Caleb B

    07/22/2025, 12:27 AM
    I think it's silly that we can't overload property setters. It's a fundamental Java feature and idiom, and it's so necessary that it's actually in the language already in a more brittle form: kotlin-assignment-plugin. The difference is that that plugin overloads the assignment operator itself to do completely unseen behavior, which is significantly less stable than just allowing setter overloading. Heck, it even has precedent for delegating to other setters for the same property: using
    item = value
    instead of
    field = value
    . I want your help to workshop a KEEP for this. Right now, my idea for it is:
    Copy code
    var foo: () -> String
        get() = field
        set(value: () -> String) {
            field = value
        }
        set(value: String) {
            foo = { value }
        }
    💡 2
    g
    c
    • 3
    • 13
  • y

    Youssef Shoaib [MOD]

    07/25/2025, 6:13 PM
    A transitional annotation for changing a DSL from passing receivers to passing contexts may be really nice to have. @Alejandro Serrano.Mena ran into this issue where using
    context
    consistently, even for DSL builders that pass a single context, is superior for a nice experience. Maybe this annotation makes a receiver only appear as a context for users that have contexts enabled, thus preparing for when everyone has them enabled to then "flip the switch". It can then also warn users who refer to
    this
    explicitly for an annotated receiver and recommend changing to
    contextOf
    instead. Perhaps a similar thing can also be applied to methods that take in an extension receiver now but want to take a context in the future, but that feels less useful for DSLs you can simple
    @Deprecate
    the extension version and introduce the context version right away, but you can't do the same with block DSLs
    plus1 1
    d
    • 2
    • 1
  • c

    CLOVIS

    07/27/2025, 6:11 PM
    I'm currently migrating a codebase that used a lot of dollars in string literals to using multi-string literals, and while the language feature itself is great, the tooling support… could be improved. Let's take this snippet:
    Copy code
    val foo = "\$foo"   // Warning: add interpolation prefix
    println("""
    	foo: $foo
    """.trimIndent())
    Let's follow the warning. We get:
    Copy code
    val foo = $$"$foo"
    println("""
    	foo: $foo
    """.trimIndent())
    So far, so good. But now, the variable is pointless. Let's inline it, we get:
    Copy code
    println("""
    	foo: $foo       // doesn't compile
    """.trimIndent())
    Sometimes, it does actually inline it into:
    Copy code
    println("""
    	foo: ${$$"$foo"}
    """.trimIndent())
    which was probably not the intent behind the KEEP. There is no inspection there to add an interpolation prefix. There is also no inspection for:
    Copy code
    println("""
        foo: ${"\$foo"}
    """.trimIndent())
    Code highlighting frequently gets it wrong (e.g. see attached screenshot). In the end, I'm pretty much did the entire migration manually. Especially now that the team is proposing changing existing syntax in every other KEEP, I'm worried that tooling is being left off as an afterthought.
    b
    • 2
    • 3
  • s

    Shaun Wild

    08/10/2025, 11:49 AM
    Would
    MultipleChoices
    not qualify for context sensitive resolution here? It's a list of sealed class (from KOOG)
    d
    • 2
    • 2
  • b

    Bernhard

    08/11/2025, 2:33 PM
    regarding rich errors: looking at the code it seems like at least ?. syntax will not be able to distinguish between a null and an error; is that intended?
    👌 1
  • r

    Rafael Costa

    08/13/2025, 9:48 AM
    Hey guys 👋 I'm sorry if I'm not in the right channel, I didn't find a better one, but I think it's related enough. I'm trying context parameters, but failing in this case:
    Copy code
    fun bar(
        lambda: context(String) () -> Unit
    ) {
        with("") {
            lambda()
        }
    }
    
    fun foo() {
        bar {
            this // error
        }
    }
    Am I missing something? Is this not supposed to give me a string? I am not able to get the context parameter of the lambda in any way. If I try
    bar { str ->
    then "str" here is also an error 🤔
    j
    h
    +2
    • 5
    • 8
  • c

    CLOVIS

    08/13/2025, 1:46 PM
    https://github.com/Kotlin/KEEP/issues/445 has been created as an issue but the other recent KEEPs were created as discussions, was there a change in policy?
    m
    • 2
    • 1
  • c

    CLOVIS

    08/20/2025, 12:16 PM
    Why are non-tail-recursive functions marked with
    tailrec
    only a warning and not an error?
    y
    j
    e
    • 4
    • 9
  • r

    rnett

    08/21/2025, 7:58 PM
    Very interesting JVMLS talk on "typeclasses" in Java:

    https://www.youtube.com/watch?v=Gz7Or9C0TpM▾

    . If it does make it into the language it's likely to come into Kotlin in some form for interop, and it's also something that Kotlin can't really do at the moment.
    y
    • 2
    • 2
  • s

    Shaun Wild

    08/22/2025, 3:36 PM
    Context sensitive resolution: why doesn’t it work for classes in sealed hierarchies?
    c
    a
    • 3
    • 9
  • s

    Shaun Wild

    08/26/2025, 9:16 AM
    Does JB state anywhere the recommended code style for enums? I see many projects including JB are moving to CamelCase over SNAKE_CASE
    m
    c
    • 3
    • 5
  • h

    Hunter

    08/26/2025, 7:15 PM
    Is there a way to mark a class constructor as private-in-file? Currently I have to use
    internal
    to get the closest behavior but I really would want it to only be accessible in-file. If not, would be very nice to have.
    ➕ 3
    g
    a
    +3
    • 6
    • 11