https://kotlinlang.org logo
Title
m

Mark

10/31/2018, 4:43 AM
var x = ...
when (x) is X ->
// cannot use x as X unless use
x as X
Is there any other way apart from make
val x
?
g

gildor

10/31/2018, 5:11 AM
Could you show some self contained sample, it’s not clear what you want to do
m

Mark

10/31/2018, 5:14 AM
If you pass a
val
into
when
, then smartcasting is available. Otherwise it is not and so you have to do
x as X
. It’s not an unreasonably workaround, but just curious if there is a better way.
g

gildor

10/31/2018, 5:17 AM
I still don’t understand the problem. Smartcast available after any type check or unsafe type cast and not related directly to
when
m

Mark

10/31/2018, 5:45 AM
not when the type being checked is a
var
. True that this issue is not specific to
when
but workaround/solution may be specific to
when
Essentially, I’m asking is there something like
it
to avoid the recast?
g

gildor

10/31/2018, 5:51 AM
this is why I asked about some complete example
it
cannot be used with
when
it would be backward incompatible change
m

Mark

10/31/2018, 5:52 AM
It’s a shame (no pun intended).
g

gildor

10/31/2018, 5:52 AM
there is new syntax in 1.3, maybe can help you somehow:
when (val x = doTypeCheckOrCast()) {
   x // here is val and type safe
}
m

Mark

10/31/2018, 5:52 AM
Oh interesting, thanks!
g

gildor

10/31/2018, 5:53 AM
I really would like to see some real code snippet, maybe it can be solved in a different way
also smart cast works with
var
if it’s local variable and cannot be changed by some other part of your code
s

stevecstian

10/31/2018, 5:54 AM
Is
x
an open property or has custom getter?
g

gildor

10/31/2018, 5:55 AM
m

Mark

10/31/2018, 5:55 AM
just a local
var =
g

gildor

10/31/2018, 5:55 AM
smart cast works for local
var
m

Mark

10/31/2018, 5:56 AM
Hmmm, doesn’t seem to for me
when(val x = x)
seems to do the trick
but for exactly the same code
when(x)
does not allow smartcast
s

stevecstian

10/31/2018, 5:57 AM
If would be helpful if you could show us the code in pl.kotl.in
g

gildor

10/31/2018, 5:57 AM
maybe you also could share your sample there
This example using
when
, smartcast also works https://pl.kotl.in/HyqoVpU3X
👍 1
m

Mark

10/31/2018, 6:05 AM
Ok I see now. The reason because “is a local variable that is captured by a changing closure”
Presumably from one of the `let`s thats surrounding what needs to be smart casted.
g

gildor

10/31/2018, 6:09 AM
what is your use case for
let
in this example?
Maybe you also could avoid usage of
var
hard to tell something on this too synthetic code snippet
m

Mark

10/31/2018, 6:10 AM
g

gildor

10/31/2018, 6:11 AM
still usage of
let
not clear for me and probably can be avoided
same for
var
m

Mark

10/31/2018, 6:11 AM
For sure the
Any().let
is just to show the impact of
let
but you can imagine something useful in there
The
var
is necessary because it’s reassigned later
g

gildor

10/31/2018, 6:13 AM
Yes, in this sample, but probably original code can be rewritten in the way when it is not needed
Sure, this works, because you make x immutable
To be honest I’m not sure why smart cast doesn’t work in this case
because
let
uses contracts
and have contract to be called exactly once
m

Mark

10/31/2018, 6:15 AM
Okay thanks, so in this case what is the best workaround? is it to put
val x = x
before the
let
?
g

gildor

10/31/2018, 6:16 AM
Imo the best workaround to rewrite code and make x immutable
👍 1
val x = x
also fine
I use this approach a lot
m

Mark

10/31/2018, 6:18 AM
Ok. I think in the case of
when
I quite like
when(val x = x)
but yes it seems like it should be nearer the
let
because that is what is causing the issue
s

stevecstian

10/31/2018, 6:31 AM
m

Mark

10/31/2018, 6:40 AM
I’m not sure I understand this. How could the code be modified to take advantage of this: https://pl.kotl.in/S1fDdaI2m
So I guess we have to wait until KT-7186 got fixed.
g

gildor

10/31/2018, 6:48 AM
Actually in think KT-7186 should be extended to contracts, because in case of let there is also contract that already used by compiler, but not in this case
d

dsavvinov

10/31/2018, 8:16 AM
Actually in think KT-7186 should be extended to contracts, because in case of let there is also contract that already used by compiler, but not in this case
Yes, we have it on the table. It requires a bit more work than it may appear, though.
👍 2
g

gildor

10/31/2018, 8:16 AM
Good to hear 👍