How do you deal with `NSInteger` in common Darwin code? :open_mouth:

# multiplatform

[Marc Knaup]

How do you deal with NSInteger in common Darwin code? 😮

[louiscad]

You have both 32 and 64 bits targets?

[Marc Knaup]

Yes

[louiscad]

Then, it doesn't work yet unfortunately

[Marc Knaup]

😅

[louiscad]

I dealt with it by not using commonizer but hacking deep instead.

[Marc Knaup]

Maybe I can add Int.toNSInteger() and NSInteger.toInt() extensions in each target with actual/expect?

[louiscad]

You can try, I'm curious if it'd work.

[louiscad]

I'd use Long in place of Int if there's a risk to go over ~2 Billion.

[Marc Knaup]

Yeah depends on the use case, just like .toInt() vs .toLong().
0 is always good 🙂

[Marc Knaup]

It works!

[Marc Knaup]

Why the heck is NSInteger = <http://kotlin.Int|kotlin.Int> on watchos-arm64?

[louiscad]

Because watchOS is weird IIRC

[louiscad]

Maybe for similar reasons as to why x86 Android emulator is faster than x86_64 emulator on 64 bit desktops/laptops?

[louiscad]

I guess Swift developers don't notice it because of the language design

[louiscad]

You had to expect actual it on all individual targets, right?

[Marc Knaup]

Yes

[Marc Knaup]

https://github.com/fluidsonic/fluid-time/tree/master/sources/darwin/extensions

[louiscad]

Cool that it works, that's an interesting workaround if you can limit that to a small amount of code

[Marc Knaup]

Yeah and you could probably also share this as a reusable library

[louiscad]

I think I'm going to use that hack in #splitties as well

[louiscad]

I think this issue will be fixed in a few months by Kotlin 1.4.20 though

[Marc Knaup]

🤷‍♂️ would be nice

[Jurriaan Mous]

Relevant issue https://youtrack.jetbrains.com/issue/KT-39324

[Marc Knaup]

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.

[Jurriaan Mous]

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.

[louiscad]

@Jurriaan Mous Aren't Swift's Int actually NSInteger s?

[Marc Knaup]

It would be rather unexpected if Kotlin’s Int randomly switches from 32 to 64 bit like Swift’s Int 🤔

[russhwolf]

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

[russhwolf]

But more often I’ve done an explicit expect/actual for 32-bit and 64-bit

[Jurriaan Mous]

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.

[Marc Knaup]

Yes, Kotlin could make NSInteger and NSUInteger proper integer types and povide all the conversions and operations on its own.

[louiscad]

@Marc Knaup Basically, all watchOS targets have Swift's Int (aka. NSInteger) resolve to a 32 bit integer (aka. Kotlin's Int), right?

[Marc Knaup]

@louiscad that's how I understand it. I haven't tested that though.

[russhwolf]

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