Is this a known issue ``` fun main args Array lt String gt v

Question

Is this a known issue ``` fun main args Array lt String gt val foo = object var foo Int = null foo foo = 5 println foo foo Yields Smart cast impossible because foo foo is a mutable property ```

McEna · Answer

Delete the

McEna · Answer

println signature does not recognize the null type so either declare var foo Int or change the println call to println foo foo

McEna · Answer

that way you discard the null type

Andreas Sinz · Answer

`println Any ` is available furthermore if i place `println` before `foo foo = 5` it works

McEna · Answer

At that point type inference resolves to null that s why it works Once you mutate the variable kotlin is unsure of which one use because the actual type is Int or null and Int matches one signature and null another

McEna · Answer

I agree it should work as it is but I ve found kotlin s type inference is quite fragile because it scans the type each time the object is used

Sam · Answer

println $ foo foo

McEna · Answer

for example if you have a couple functions returning T where lt T SomeType gt and then chain both methods in one T subclass a generic fluent api Kotlin will ask you to provide the actual type but only at the last call

McEna · Answer

it will ignore all the previous inferences

McEna · Answer

So everytime you have several signatures you have to provide the type Kotlin will not choose the generic one like java does

Dico · Answer

Can you give an example of that Francisco

McEna · Answer

Sure

McEna · Answer

Let s suppose we want a fluent API so our setters will return the object And we will have a huge hierarchy sharing some fundamental properties like the android view hierarchy so we need to make those setters generic so every subclass will return an instance of itself

McEna · Answer

public class Example extends somethingElse protected String Icon = protected String title public Example public String getIcon return this Icon public lt T extends Example gt T setIcon String icon this Icon = icon return this public String getTitle return this title public lt T extends Example gt T setTitle String title this title = title return this ExampleSubclass javaObject = new ExampleSubclass 1234 abc setTitle atitle ExampleSubclass javaObject = new ExampleSubclass 1234 abc setTitle atitle setIcon someAsset ExampleSubclass setTitle OHOHOHO ExampleSubclass setTitle lt ExampleSubclass gt OHOHOHO setIcon someAsset

McEna · Answer

Java manages to run that code because it does not infer the type so T is always resolved against the first declaration Therefore you can chain as much calls as you like and the type declared at the left will be used as T

McEna · Answer

Kotlin in the other hand ignores the previous statement everytime an assigment happens forcing you to declare the type despite the fact you already have it declared because it solves the types at the last moment

McEna · Answer

is a very unlikely case since kotlin has apply for these cases but shows the difference