any reason Kotlin doesn't use

Integer

for

lateinit num: Int

Why not just set

num

to an arbitrary number by default, since it’ll be set later anyway?

@Andrew Gazelka I believe it's to avoid the unexpected overhead of autoboxing, but don't quote me on that.

@serebit why have nulls at all if they will just be set later anyway?

False equivalency. If you’re using lateinit, you’re making a guarantee that the value isn’t going to be used until it’s set.

this sounds like micro-optimization to me

https://stackoverflow.com/a/49594199

Normally, properties declared as having a non-null type must be initialized in the constructor. However, fairly often this is not convenient. For example, properties can be initialized through dependency injection, or in the setup method of a unit test. In this case, you cannot supply a non-null initializer in the constructor, but you still want to avoid null checks when referencing the property inside the body of a class.

esp since there is no way to make

lateinit Integer

In that case, I'm not sure.

Correct, because there’s no reason why you’d need to. You can just set it to zero, or some other arbitrary number.

@serebit so you are saying if all objects had a default value implementation we wouldn't need null?

I’m not sure why you’re putting words in my mouth, because that’s not what I’m saying.

I don't see how I am putting words in your mouth. Maybe I am not paying attention closely enough...

The value can’t be set to null, so a placeholder value can be used before being set to the proper value. The placeholder value doesn’t matter, it’s never used, and it incurs no performance penalty. So what’s your use case? Why do you require lateinit, if using a default value that’s overwritten before the property is used works exactly the same as using lateinit would if it were supported?

because we might forget to initialize it and then the program would run without errors, even though it is not initialized

Just a casual onlooker here, but yes, if you try to access a lateinit property before it is set the app should throw an exception. Setting a default value is not the same as lateinit. As for the actual question I’m not sure why it doesn’t use

Integer

in that case.

In fairness to the language designers,

Int?

can and should be autoboxed because it might be null after being initialized. A lateinit

Int

would only be null pre-initialization, so it seems odd to box it for the entirety of the runtime.

Then add another boolean field to solve that. I find it incredibly frustrating that you can't do this as well.

But why is it frustrating? I’ve been using Kotlin for almost 3 years now and that

lateinit Int

never crossed my mind or bothered me. I assume Kotlin is going to do stuff under the hood, as long as my code works I’m not too concerned. If I had to get too nitty gritty with that stuff I’d imagine things like Kotlin/Native would be much more verbose and difficult.

Right, I don't care what happens in the background, it should just work.

It bothered me once, and when I realized that it didn’t matter and I could just use a default value instead, I immediately stopped caring

@karelpeeters I can imagine a hidden Boolean could cause all sorts of problems, especially with things like reflection.

@serebit But then you lose runtime safety.

If I forget to initialize it? Yes. So I didn’t forget to initialize it

@Ruckus Maybe, I'm not sure though. There are hidden variables generated all the time for eg. property delegation.

@serebit I agree. Programming is way easier if you just remember to never make any mistakes :trollface:

@serebit That's what safety is for, to figure out when you've made a mistake.

Lateinit is already a dodgy thing to be using and it’s only there for things that can’t be initialized where they stand. I just avoid using it in general, and when I have to, I’m careful about it. Maybe if I wanted to be sure, I’d give it a default value that would never be achieved in the program proper, and add a getter to ensure that it never returns that value

it’s only there for things that can’t be initialized where they stand

Which happens quite often anytime you use a framework with custom life cycles

Here's the discussion about how this sort of lateinit properties could be implemented: https://youtrack.jetbrains.com/issue/KT-15284