Thread
#multiplatform
    m

    Marc Knaup

    2 years ago
    How do you deal with
    NSInteger
    in common Darwin code? 😮
    louiscad

    louiscad

    2 years ago
    You have both 32 and 64 bits targets?
    m

    Marc Knaup

    2 years ago
    Yes
    louiscad

    louiscad

    2 years ago
    Then, it doesn't work yet unfortunately
    m

    Marc Knaup

    2 years ago
    😅
    louiscad

    louiscad

    2 years ago
    I dealt with it by not using commonizer but hacking deep instead.
    m

    Marc Knaup

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

    louiscad

    2 years ago
    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

    2 years ago
    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
    ?
    louiscad

    louiscad

    2 years ago
    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?
    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

    2 years ago
    Yes
    louiscad

    louiscad

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

    Marc Knaup

    2 years ago
    Yeah and you could probably also share this as a reusable library
    louiscad

    louiscad

    2 years ago
    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

    2 years ago
    🤷‍♂️ would be nice
    Jurriaan Mous

    Jurriaan Mous

    2 years ago
    m

    Marc Knaup

    2 years ago
    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

    Jurriaan Mous

    2 years ago
    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

    louiscad

    2 years ago
    @Jurriaan Mous Aren't Swift's
    Int
    actually
    NSInteger
    s?
    m

    Marc Knaup

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

    russhwolf

    2 years ago
    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
    But more often I’ve done an explicit expect/actual for 32-bit and 64-bit
    Jurriaan Mous

    Jurriaan Mous

    2 years ago
    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

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

    louiscad

    2 years ago
    @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

    2 years ago
    @louiscad that's how I understand it. I haven't tested that though.
    russhwolf

    russhwolf

    2 years ago
    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