https://kotlinlang.org logo
Join Slack
Powered by
How do you deal with `NSInteger` in common Darwin ...
# multiplatform
m
How do you deal with 
NSInteger
in common Darwin code? 😮
l
You have both 32 and 64 bits targets?
m
Yes
l
Then, it doesn't work yet unfortunately
m
😅
l
I dealt with it by not using commonizer but hacking deep instead.
m
Maybe I can add 
Int.toNSInteger()
and 
NSInteger.toInt()
extensions in each target with actual/expect?
l
You can try, I'm curious if it'd work.
I'd use 
Long
in place of 
Int
if there's a risk to go over ~2 Billion.
m
Yeah depends on the use case, just like 
.toInt()
vs 
.toLong()
. 
0
is always good 🙂
It works!
Why the heck is 
NSInteger = <http://kotlin.Int|kotlin.Int>
on 
watchos-arm64
?
l
Because watchOS is weird IIRC
Maybe for similar reasons as to why x86 Android emulator is faster than x86_64 emulator on 64 bit desktops/laptops?
🤔 1
I guess Swift developers don't notice it because of the language design
You had to expect actual it on all individual targets, right?
m
Yes
l
Cool that it works, that's an interesting workaround if you can limit that to a small amount of code
m
Yeah and you could probably also share this as a reusable library
l
I think I'm going to use that hack in #splitties as well
I think this issue will be fixed in a few months by Kotlin 1.4.20 though
m
🤷‍♂️ would be nice
j
m
I don’t think that will help here. You can commonize in multiple dimensions, for example: arm64 <- ios-arm64 & macos-arm64 & tvos-arm64 ios <- ios-arm32 & ios-arm64 & ios-x64 But you likely cannot mix those approaches. Commonizing by platform makes more sense than by architecture. But that means we still don’t know the size of 
NSInteger
in that commonized code.
j
In Swift NSInteger is 32 or 64 bit depending on architecture. We once had crashes on 32 bit devices because of it because of common Swift code. We switched to Int32/Int64. So Kotlin can handle it in the same way as Swift does and maybe recommend specific sized ints.
l
@Jurriaan Mous Aren't Swift's 
Int
actually 
NSInteger
s?
m
It would be rather unexpected if Kotlin’s 
Int
randomly switches from 32 to 64 bit like Swift’s 
Int
🤔
r
Since 
NSInteger
is just a typealias to 
Int
or 
Long
, you can sometimes get away with using 
convert()
to avoid platform-specific expect/actual. https://kotlinlang.org/api/latest/jvm/stdlib/kotlinx.cinterop/convert.html
😮 1
But more often I’ve done an explicit expect/actual for 32-bit and 64-bit
j
Int32 and Int64 I meant. Too much Kotlin lately so I misremembered. I would let Kotlin work as Kotlin so let Int be 32 bit. Only talking about NSInteger.
m
Yes, Kotlin could make 
NSInteger
and 
NSUInteger
proper integer types and povide all the conversions and operations on its own.
l
@Marc Knaup Basically, all watchOS targets have Swift's 
Int
(aka. 
NSInteger
) resolve to a 32 bit integer (aka. Kotlin's 
Int
), right?
m
@louiscad that's how I understand it. I haven't tested that though.
👍 1
r
Yes that is the case. I have this build logic in Multiplatform Settings to handle it because I need some 
NSInteger
-based expect/actuals https://github.com/russhwolf/multiplatform-settings/blob/master/buildSrc/src/main/kotlin/BuildHelpers.kt#L138-L151
👍 1
327 Views
Open in Slack
PreviousNext
Powered by