https://kotlinlang.org logo
#announcements
Title
# announcements
g

groostav

11/30/2017, 10:48 PM
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

Shawn

11/30/2017, 11:56 PM
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

groostav

12/01/2017, 12:00 AM
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

Shawn

12/01/2017, 12:02 AM
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

dave08

12/01/2017, 3:54 AM
You could always
else -> throw SomeNeverToBeSeenException("I'll hopfully never see this")
even w/o sealed class... 😜