LELelouBil·May 22, 2026Submission
Design Notes: Local Lifetimes for Kotlin
1 points · Open discussionKotlin
KEEP
Markdown2016–2026
Kotlin / KEEP
KEEP
Kotlin Evolution and Enhancement Process
18Distinct people
26Mentions
0Explicit recommenders
3.8KGitHub stars
What to know before exploring
What it is
Kotlin Evolution and Enhancement Process
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- arrow-kt/arrow-meta · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2016-04-20 17:18:24 UTC to 2026-05-22 00:03:58 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 1 | 3 |
What Hacker News says
26 sourcesKotlin itself has opted for inline union types to represent error results: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441...
The existing Result type was a mistake to expose to users, IMO, as it encourages exceptions-as-control-flow and error type hierarchies which complicate error-handling even further. The convenient `runCatching` API also completely breaks reasonable error-handling on the JVM and Kotlin's structured concurrency (which happens to use exceptions-as-control-flow to signal coroutine cancellation).
Overall, Kotlin is moving away from higher-kinded types in the core language, not toward them.
In A perfectable programming languageThese remind me of checked exceptions in Java. Ironically, Kotlin removed checked exceptions because they tend to be annoying more than useful: there's no clear guideline to whether an exception is checked or unchecked, some functions like IO and reflection have them while others don't, they're verbose especially when closures are involved, and lots of functions simply catch and rethrow checked exceptions in unchecked exceptions.
Which leads me to: why is Kotlin implementing this in a non-JVM compatible way, instead of introducing checked exceptions with better language support? All the problems stated above can be avoided while keeping the core idea of checked exceptions, which seems to be the same as this proposal.
From the GitHub discussion, I see this comment (https://github.com/Kotlin/KEEP/discussions/447#discussioncom...):
> The dif
Read the rest
ference between checked exceptions from java and error unions in this proposal is how they are treated. Checked exceptions are exceptions and always interrupt the flow of execution. On the other hand, errors in this proposal are values and can be passed around as values or intentionally ignored or even aggregated enabling the ability to use them in async and awaitAll etc.
But is this a real difference or something that can be emulated mostly syntactically and no deeper than Kotlin's other features (e.g. nullables, getters and setters)? Checked exceptions are also values, and errors can be caught (then ignored or aggregated) but usually interrupt the flow of execution and get propagated like exceptions.
> what about interop with Java?
From the proposal discussion[0], the runtime representation on the JVM will just be `Object`.
[0]: https://github.com/Kotlin/KEEP/discussions/447#discussioncom...
In Kotlin's rich errors: Native, typed errors without exceptionsYes there was a proposal by Brian to make it into a switch expression: https://news.ycombinator.com/item?id=40088719, though that draft is already 1.5 years old and I don't expect it to be delivered anytime soon. It would alleviate some pain, but I really think we need something like try! to escape the compiler when some errors aren't possible:
A a;
try {
a = someThrowingFn();
} catch (AException ex) {
throw new IllegalStateException(ex); // not possible
}
becomes
var a = try! someThrowingFn();
or with Brian's proposal:
var a = switch (someThrowingFn()) {
case A anA -> anA;
case throws AException ex -> throw new IllegalStateException(ex);
}
...still a bit verbose and funky
You should check out Kotlin's proposal for error unions, I think it's pretty good and prevents a lot of b
Read the rest
oiler plate associated with results/exceptions: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441.... They propose a similar construct to try! with !! like they have for nullable types.
> So if you had 3 different disjoint exception types that you simply wanted to wrap and rethrow, you had to write 3 different catch blocks for them.
Agreed. There's a proposal for exception catching in switch [0] which I'm hopeful will alleviate a lot of this. I think that jep plus combining exceptions with sealed types the error handling will be convenient and easy.
sealed abstract class SomeException extends Exception permits AException, BException {};
void someFn() throws SomeException;
// hypothetically handling in switch would let you enumerate the subtypes of the exception
var a = switch (someFn()) {
case A a -> a;
case throws AException aex -> new A();
case throws BException bex -> throw new RuntimeException(bex);
};
> As another example, the exception type hierarchy doesn't pul
Read the rest
l enough weight.
Kotlin has an interesting proposal for their language that creates their own "error" type that will allow type unions [1]. The only thing I worry about is that it further puts Kotlin away from Java making interop a lot harder.
[0] https://openjdk.org/jeps/8323658
[1] https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441...
They also failed because Java never made them easy to work with. If you faced a checked error that you couldn't handle it is impractical to uncheck them. You have to write a shit ton of boilerplate.
A a;
try {
a = someThrowingFn();
} catch (AException ex) {
throw new RuntimeException(ex);
}
It sucks. In Swift this is simply: val a = try! someThrowingFn(); Kotlin is moving towards having both unchecked exceptions (panics) and errors as values. I think its absolutely the correct decision. They're also including an easy way to panic when you can't handle an error: val a = someThrowingFn()!!;
The other thing that I think made checked exceptions worse in the beginning was the lack of pattern matching and sealing with exceptions. Being able to exhaust all the different types of a particular error is really impor
Read the rest
tant if you want to properly respond. If you had a meaningless top level exception like IOException you couldn't effectively determine what actually happened and everyone just defaulted to unchecking it. Nowadays it's a little better if you seal your exception hierarchy:
sealed abstract class SomeException extends Exception permits A, B {
final class B extends SomeException {}
final class C extends SomeException {}
}
try {
someThrowingFn();
} catch (SomeException ex) {
switch (ex) {
case A a -> iCanHandleA(a);
case B b -> throw new IllegalStateException(b); // can't handle this one
}
}
Hopefully that becomes even better with the exceptions in switch [1] proposal:
switch (someThrowingFn()) {
case throws A a -> ..
case throws B b -> ..
}
The real big issue like you said is that they're not completely in the type system. Especially when it comes to lambdas; you need to invent a Result<T, E> type every time you want to work with lambdas. Obviously all of these things are solvable with library code, try! is easily some static panic function; it sure would be nice to not have to write them. Overall I'm hopeful that with the overall programming community moving back towards checked errors that the OpenJdk team will invest in making checked exceptions better, but only time will tell.
[0] github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md
[1] https://openjdk.org/jeps/8323658
Rich Errors, a.k.a. Error Union Types: Motivation and Rationale
3 points · Open discussionNo, and it won't. Checked exceptions were explicitly removed compared to Java, and most people view them as a mistake (including the Java 8+ ecosystem e.g. streams).
Try is a bit better and Kotlin has a bit of that with Result + runCatching. You can find a pretty good overview of the Kotlin error handling phylosphy here [1]
[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
In What's New in Kotlin 2.0.0`Either<MyError, Foo> foo()` and `Foo foo() throws MyError` and are pretty much isomorphic.
https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
In JEP draft: Exception handling in switchNice. So for example, it looks like Kotlin already has a nearly identical feature at the language level, which will be optimizable when Valhalla ships: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
> In the future, in a Valhalla-capable JVM, JVM primitive classes will enable efficient representation of Kotlin value classes with an arbitrary number of underlying fields on JVM.
In Project Valhalla: A look inside Java's epic refactorMost other languages agree that checked exceptions are not good by not having them.
As for alternatives, Try/Result and similar monads have decent adoption even in Java, but personally I quite like the Kotlin philosophy [1] to not have generic error containers and either use runtime exceptions for errors that cannot be reasonably handled by the caller and encapsulate failures in the return type if they can.
[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
In Unchecked Java: Say goodbye to checked exceptionsLenses work today. And I think the value class feature will be awesome.
https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
In Making Lenses Practical in JavaKotlin has value classes. Here's a good overview of how they work in Kotlin: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
That document is a few years old now and was intended as a design document. But Value classes shipped with Kotlin 1.5. Apparently they are compatible with the project Valhalla value objects that will be added to the JVM at some point. So, this stuff is coming.
I had to look it up because even though I write Kotlin a lot, value classes are not something I have used at all. Looks useful but not that big of a deal and doesn't really solve a problem I have. Data classes and records (in Java) are a bigger deal IMHO.
In practice, the way you deal with immutability in Kotlin is to keep most of your data structures immutable by default unless they need to be mutable. E.g. there's a List and a MutableList int
Read the rest
erface. Most lists are immutable unless you create a MutableList. Same with val vs. var variables. Val variables can't be reassigned and you kind of use var only by exception when you really have to. The compiler will actually warn you if you do it without good reason. A data class with only vals can't be modified. Java is a bit more sloppy when it comes to mutability semantics. It has records now but all the fields have setters by default. It has var but no val assignments (you can use final to force this but few people do). And so on.
Semantically this is not as strong as what Rust does of course but it's good enough to make e.g. concurrency a lot easier. Mostly, if you avoid having a lot of mutable shared state, that becomes a lot easier.
You could imagine a Kotlin like language with much stronger semantics implementing borrow checking instead of garbage collection. It wouldn't be the same language of course but I don't think it needs to be very different. Using it would not be a massively different.
I'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context...
In Java record pattern matching in JDK 19Showing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.