CLOVIS
05/27/2025, 7:14 PMEdoardo Luppi
05/29/2025, 9:18 AMCLOVIS
05/29/2025, 4:03 PMfun foo(range: ClosedRange<*>) {}
fun foo(range: OpenEndRange<*>) {}
foo(5..12)
gets
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?mikhail.zarechenskiy
06/03/2025, 8:39 AMPerson(@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?CLOVIS
06/05/2025, 12:49 PMerror 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.Youssef Shoaib [MOD]
06/05/2025, 4:37 PMAlejandro Serrano.Mena
06/06/2025, 9:14 AMcketti
06/06/2025, 12:13 PM"\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.)Edoardo Luppi
06/09/2025, 1:46 PMYoussef Shoaib [MOD]
06/11/2025, 2:13 AMsuspendCoroutineUninterceptedOrReturn
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 muchjNayden
06/11/2025, 6:41 AMrnett
06/16/2025, 6:37 AMlocal
parameters mentioned in the outference talk? I was not able to find any myselfYoussef Shoaib [MOD]
06/17/2025, 7:37 PMInlineOnly
.vngantk
06/20/2025, 10:22 PMGhasem Shirdel
06/27/2025, 2:46 PMRafael Diaz
06/29/2025, 9:36 PMinternal
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.CLOVIS
07/17/2025, 1:48 PMcompanion data object
is forbidden?Caleb B
07/22/2025, 12:27 AMitem = value
instead of field = value
.
I want your help to workshop a KEEP for this. Right now, my idea for it is:
var foo: () -> String
get() = field
set(value: () -> String) {
field = value
}
set(value: String) {
foo = { value }
}
Youssef Shoaib [MOD]
07/25/2025, 6:13 PMcontext
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 DSLsCLOVIS
07/27/2025, 6:11 PMval foo = "\$foo" // Warning: add interpolation prefix
println("""
foo: $foo
""".trimIndent())
Let's follow the warning. We get:
val foo = $$"$foo"
println("""
foo: $foo
""".trimIndent())
So far, so good. But now, the variable is pointless. Let's inline it, we get:
println("""
foo: $foo // doesn't compile
""".trimIndent())
Sometimes, it does actually inline it into:
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:
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.Shaun Wild
08/10/2025, 11:49 AMMultipleChoices
not qualify for context sensitive resolution here? It's a list of sealed class (from KOOG)Bernhard
08/11/2025, 2:33 PMRafael Costa
08/13/2025, 9:48 AMfun 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 🤔CLOVIS
08/13/2025, 1:46 PMCLOVIS
08/20/2025, 12:16 PMtailrec
only a warning and not an error?Shaun Wild
08/22/2025, 3:36 PMShaun Wild
08/26/2025, 9:16 AMHunter
08/26/2025, 7:15 PMinternal
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.