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
308 Views