https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
m

Marc Knaup

08/25/2020, 11:11 AM
How do you deal with
NSInteger
in common Darwin code? 😮
l

louiscad

08/25/2020, 11:12 AM
You have both 32 and 64 bits targets?
m

Marc Knaup

08/25/2020, 11:12 AM
Yes
l

louiscad

08/25/2020, 11:12 AM
Then, it doesn't work yet unfortunately
m

Marc Knaup

08/25/2020, 11:13 AM
😅
l

louiscad

08/25/2020, 11:13 AM
I dealt with it by not using commonizer but hacking deep instead.
m

Marc Knaup

08/25/2020, 11:13 AM
Maybe I can add
Int.toNSInteger()
and
NSInteger.toInt()
extensions in each target with actual/expect?
l

louiscad

08/25/2020, 11:14 AM
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

Marc Knaup

08/25/2020, 11:15 AM
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

louiscad

08/25/2020, 11:35 AM
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

Marc Knaup

08/25/2020, 11:38 AM
Yes
l

louiscad

08/25/2020, 11:39 AM
Cool that it works, that's an interesting workaround if you can limit that to a small amount of code
m

Marc Knaup

08/25/2020, 11:40 AM
Yeah and you could probably also share this as a reusable library
l

louiscad

08/25/2020, 11:40 AM
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

Marc Knaup

08/25/2020, 11:42 AM
🤷‍♂️ would be nice
j

Jurriaan Mous

08/25/2020, 1:16 PM
m

Marc Knaup

08/25/2020, 1:21 PM
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

Jurriaan Mous

08/25/2020, 1:29 PM
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

louiscad

08/25/2020, 1:30 PM
@Jurriaan Mous Aren't Swift's
Int
actually
NSInteger
s?
m

Marc Knaup

08/25/2020, 1:30 PM
It would be rather unexpected if Kotlin’s
Int
randomly switches from 32 to 64 bit like Swift’s
Int
🤔
r

russhwolf

08/25/2020, 1:46 PM
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

Jurriaan Mous

08/25/2020, 1:50 PM
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

Marc Knaup

08/25/2020, 1:52 PM
Yes, Kotlin could make
NSInteger
and
NSUInteger
proper integer types and povide all the conversions and operations on its own.
l

louiscad

09/05/2020, 7:44 PM
@Marc Knaup Basically, all watchOS targets have Swift's
Int
(aka.
NSInteger
) resolve to a 32 bit integer (aka. Kotlin's
Int
), right?
m

Marc Knaup

09/05/2020, 9:41 PM
@louiscad that's how I understand it. I haven't tested that though.
👍 1
r

russhwolf

09/05/2020, 10:07 PM
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
140 Views