I mean I really likes the smart casts, this feels ...
# getting-started
u
I mean I really likes the smart casts, this feels like a step back
s
the point of smart casting isn’t to be lazy, it’s to be safe
u
whats the issue? that it doesnt know its kotlin in the other module?
s
even if it were Kotlin in the foreign code, it could have a computed getter
u
how come it works on the same module code then
s
it won’t work in the same module if it has a computed getter
u
I see
can contracts or whatever help in future?
s
no, consider the following, valid and representable computed getter
Screen Shot 2020-04-08 at 11.34.46 PM.png
u
yea computed getter I get, I mean real vals
s
here it is in text form if the screenshot is hard to read
Copy code
class Foo {
  val bar: Int?
    get() = if (Random.nextInt() % 2 == 0) 4 else null
}

fun bar(foo: Foo) {
    if (foo.bar != null) {
        acceptsInt(foo.bar)
    }
}
u
constant dataclass vals, from another module, can I nudge compiler somehow to accept it?
if its "my" code
s
you gotta draw the line somewhere, and the line was drawn at modules
Maybe in the future the JB folks will come up with a way to safely relax those requirements, but for the time being those are the rules, and they’re there to keep us from shooting our feet off
u
I understand, but, wondering if its a setting or a maybe some metaprogramming of contracts etc
on the typeinference
s
this problem is out of the scope of the type system though
and contracts can’t really guarantee the safety of external code
u
I mean it did work until recently I think, I thought it was the new type inference engine
unless im wrong
s
in the three years I’ve been writing Kotlin, I’ve never seen this work
maybe a long time ago before 1.0 this could’ve been the case but I have no idea
u
really? nevermind then, thanks
👍 1
k
this kinda what I do most of the time