https://kotlinlang.org
Join Slack
any reason Kotlin doesn't use `Integer` for `lateinit num: Int`
# announcements
a
any reason Kotlin doesn't use 
Integer
for 
lateinit num: Int
since it uses 
Integer
for 
Int?
s
Why not just set 
num
to an arbitrary number by default, since it’ll be set later anyway?
r
@Andrew Gazelka I believe it's to avoid the unexpected overhead of autoboxing, but don't quote me on that.
a
@serebit why have nulls at all if they will just be set later anyway?
sounds like a strawman to me
s
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.
What it’s set to before that point doesn’t matter, and ints have no overhead, so I don’t see why lateinit is necessary here. Using lateinit would also incur a permanent boxing overhead like Ruckus mentioned.
a
this sounds like micro-optimization to me
r
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.
a
esp since there is no way to make 
lateinit Integer
it is forced
r
In that case, I'm not sure.
s
Correct, because there’s no reason why you’d need to. You can just set it to zero, or some other arbitrary number.
What’s your use case?
a
@serebit so you are saying if all objects had a default value implementation we wouldn't need null?
I think 
lateinit
is nice because if we do make a mistake and forget to initialize it properly, we won't get weird errors
similar to how returning 
-1
from a function instead of 
null
is kinda jank (and esp bad if the range of the fun is 
[-inf,inf]
s
I’m not sure why you’re putting words in my mouth, because that’s not what I’m saying.
a
I don't see how I am putting words in your mouth. Maybe I am not paying attention closely enough...
or don't understand what you are trying to say
s
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?
a
because we might forget to initialize it and then the program would run without errors, even though it is not initialized
☝🏻 2
s
Even if lateinit for ints were implemented, it would have to set the value to a placeholder, because null can’t be used here.
c
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.
The running theory of @Ruckus sounds the most sane though. I would be curious about why it matters what Kotlin is doing behind the scenes (not as a jab, but truly curious about the usecase).
s
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.
k
Then add another boolean field to solve that. I find it incredibly frustrating that you can't do this as well.
c
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.
k
Right, I don't care what happens in the background, it should just work.
👍 2
s
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
r
@karelpeeters I can imagine a hidden Boolean could cause all sorts of problems, especially with things like reflection.
k
@serebit But then you lose runtime safety.
s
If I forget to initialize it? Yes. So I didn’t forget to initialize it
k
@Ruckus Maybe, I'm not sure though. There are hidden variables generated all the time for eg. property delegation.
r
@serebit I agree. Programming is way easier if you just remember to never make any mistakes 🧌
🧌 2
k
@serebit That's what safety is for, to figure out when you've made a mistake.
s
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
r
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
i
Here's the discussion about how this sort of lateinit properties could be implemented: https://youtrack.jetbrains.com/issue/KT-15284
👍 1
11 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by