Something that has been bugging me for a while. Wh...

# announcements

[gbaldeck]

Something that has been bugging me for a while. What is the reasoning behind not allowing latinit val in Kotlin?

[streetsofboston]

If you have set up the dependencies of the class that has this val myLateVal correctly, you can use by lazy to postpone evaluation of this val.

[streetsofboston]

val myLateInitFullName by lazy { dep1.firstName + "." + dep1.lastName }

[Mike]

Fundamentally, val implies immutable. But lateinit means it won't be set right away, and will be changed at some point to point to something real. var makes that aspect clear.

I also suspect var was chosen as we're being trained to not want to see var, so we'll be more inclined to look at alternatives.

Constructor injection, lazy or other approaches so that we don't have a var in our code.

[gbaldeck]

In a local function, you don't have to set a val immediately, so technically all local val variables are optionally lateinit. The only thing I can think of is that they did it because of concurrency reasons. For instance, in Dart, they allow late final fields, but Dart is single-threaded.

[diesieben07]

lateinit was designed primarily for interop with "injection by magic" frameworks, e.g. DI without constructor injection.
In those cases lateinit marks a property as publicly accessible and designed to be modified by third party code. Because it's third party code you cannot guarantee that it's not going to be modified more than once. So it's a var

[gbaldeck]

Sure, with setter injection that makes sense. But why not have a lateinit val also just for everyday use? It doesn't have to be final when it compiles to Java. It can be a normal variable but the immutability is enforced by the Kotlin compiler.

[diesieben07]

That's what by Delegates.notNull() is for. lateinit fundamentally only works for reference types

[gbaldeck]

I just read about Delegates.notNull(), and that is not what its for at all. It is basically lateinit for primitive types. How does it allow you to do a lateinit val exactly?

[diesieben07]

Maybe I am misunderstanding you then...

[diesieben07]

And notNull is definitely not just for primitive types.

[gbaldeck]

Thats what it was designed for... if its not a primitive type you might as well just use lateinit. https://americanexpress.io/advanced-kotlin-delegates/

[diesieben07]

lateinit is a kludge for interaction with "lets inject stuff into fields" frameworks. Delegates.notNull() is a standard built-in delegate for properties that will be initialized at a later point in time.

[diesieben07]

lateinit is not just "this will be initialized later", it also has @JvmField built-in.

[gbaldeck]

Ok, but it is used quite regularly just for the purpose of initializing the variable at a later time. So it would be nice if val had that as well. Other languages do, and the only reason I can see Kotlin not having some sort of feature like that is for concurrency reasons.

[diesieben07]

This sounds like the job for a built-in delegate, maybe Delegates.initializedOnce.

[diesieben07]

In general you don't want a new language syntax for every small feature

[gbaldeck]

And that would only work at runtime, no developtime or compiletime catching

[diesieben07]

lateinit var also has no compile-time checking.

[diesieben07]

What kind of compile-time checking do you propose? How would the compiler "know"?

[gbaldeck]

I don't claim to be a compiler expert, but other language have this feature I am speaking of, with development time and compile time checking, so it is do-able

[diesieben07]

What kind of compile-time checking is done? Like, which kind of errors are reported?

[gbaldeck]

lets you know if it was initialized twice

[gbaldeck]

or if you try to use it and it hasnt been initialized

[diesieben07]

There is no way for a compiler to proof that, unless we are speaking about local values, which already have this.

[gbaldeck]

there is a way

[diesieben07]

No, it's the halting problem effectively.

[gbaldeck]

You can do it right here

[gbaldeck]

https://nullsafety.dartpad.dev/

[diesieben07]

What am I looking at?

[gbaldeck]

I will create it for you and send the link

[diesieben07]

ok

[gbaldeck]

well I feel like an idiot, looks like you are correct. I guess I didn't play around with this as much last night as I thought. This is what I was thinking would get development time and compile time checking though:

[gbaldeck]

class Test {
  late final String value;
  
  init(){
    value = "test";
    value = "test";
  }
}

[gbaldeck]

If you copy and paste that into https://nullsafety.dartpad.dev/ you'll see that you are correct, my mistake

[diesieben07]

No worries. But think about it, as soon as you have complex conditions involved (possibly even involving things like network requests) there is no way for the compiler to prove this.

[diesieben07]

It's effectively the halting problem.

[gbaldeck]

Havent had any actual CS since I got my BS in CS about 10 years ago now, so didnt consider the halting problem. But I understand now