slightly connected Q: the return type of a Java me...

# announcements

[nkiesel]

slightly connected Q: the return type of a Java method getFoo which returns an object of type Foo (and never returns null) is Foo!. Should I (a) ignore this and use val foo = getFoo() (b) use val foo: Foo = getFoo() or (c) val foo = getFoo()!!

[nanodeath]

I usually do (b)

[nanodeath]

also the vote's rigged, there's no C emoji 😛

[nkiesel]

I also tend to lean towards (b) because (c) looks hacky. Also, (b) is still proper Kotlin code even after getFoo was re-implemented in Koltin

[christophsturm]

I use C because its more flexible. i don’t specify types where it does not add value

[ephemient]

I go with ⓐ if I'm confident the Java does not return null, requireNotNull(getFoo()) { "message" } or checkNotNull(getFoo()) { "message" } if I'm not

[christophsturm]

A produces a warning in idea

[nkiesel]

yes, and the warning is I think well deserved because it defeats the nullability promise. All 3 will lead to a runtime error if getFoo ever breaks it's promise and returns null . but (b) and (c) at least then throw the exception at the definition instead of at the first usage.

[nkiesel]

my rule of thumb: for class properties go with (b) and for local variables with (a) or (b) depending on the scope size and how far apart the first usage is from the definition.

[ephemient]

even with ⓑ you can easily trick kotlinc: https://pl.kotl.in/DnlIWPwA6

[ephemient]

you're always going to have to deal with the potential for NPE at use site unless you put an explicit check in. I would rather write explicit messages on the checks I care about, and with most things covered, figuring out what's null from the backtrace of the other cases is much easier than the average Java codebase

[nkiesel]

WTF: yes,but that is IMHO a bug in the Kotlin compiler implementation. (BTW: took me a few seconds to realize that moving `foo`below _foo is what is required to make that work as I expected).

[ephemient]

it's a "bug" that's not fixable (at least, not without performance cost) as long as Kotlin uses Java's object model and initialization

[nkiesel]

why is that? Seems a relatively straight-forward "use before (proper) initialization" case. data flow analysis at compile time could figure that out, no?

[ephemient]

initializer can call virtual methods

[ephemient]

e.g. getFoo() defined in a parent class

[ephemient]

which could very well be in another module

[nkiesel]

is the probelm not in the order of `_foo`vs. `getFoo()`: enforcing that _foo is defined before it's first use should do the trick, no? (And yes: I realize that this could break existing code)

[ephemient]

https://pl.kotl.in/GxGd2hkM7

[nkiesel]

Ok, you got me. This is happening because order is:
1. Foo constructor
2. Bar constructor
3. Foo initializtion
4. Bar initialization
correct? And why is that not a bigger problem? or was that a case of me being both ignorant and lucky?

[ephemient]

Kotlin construction order: super constructor, primary constructor, init blocks in order of appearance, then secondary constructor

[ephemient]

in this case: Foo._foo is initialized first, then Foo.foo which calls Bar._foo which is not yet initialized, then finally Bar._foo

[ephemient]

I don't know what your background is, but I can understand this behavior being surprising if you come from C++ - the object identity during the superconstructor is the superclass, so it won't call the derived class's methods. (which leads to different pitfalls, but anyway) however, Kotlin's behavior is Java's behavior, that's just how the JVM works

[Peter Ertl]

use a @Nullable / @Nonnull annotation that is processed by the kotlin compiler: https://kotlinlang.org/docs/java-interop.html#nullability-annotations

[Peter Ertl]

that will fix the return type to not be Foo! but Foo