nah its great, kitchen sink.
# announcements
g
nah its great, kitchen sink.
🚰 1
@Shawn I created akotlin discussion post on this, lemmi know what you think: https://discuss.kotlinlang.org/t/a-good-bad-idea-use-a-constraint-solver-to-proove-when-exhaustiveness/5632
s
honestly this is a bit out of my wheelhouse, so I don’t have a whole lot of useful input here 😅
but considering that the language works pretty well without the inclusion of an SMT solver, and the fact that
when
defaults to “safely” error if the statement isn’t trivially determinable to be exhaustive, I doubt anyone working on the compiler is going to consider this kind of thing for a long while
Kotlin’s overall a pretty pragmatic language, and this is decidedly not the most pragmatic option
at least, perhaps, until someone figures out whether or not boolean satisfiability even has a polynomial time algorithm 😛
g
hahaha, my thoughts also, but I guess the question I'm trying to get at is when will it become pragmatic?
when jetbrains revenue cracks the 10 Billion mark?
😄
s
haha, if computational complexity theory could be solved by throwing money at the problem, Google, Apple, and MS would have already figured out P vs NP a long while ago 😛
d
You could always
else -> throw SomeNeverToBeSeenException("I'll hopfully never see this")
even w/o sealed class... 😜