As for Arrays linear conversion we already do it using Obj-C bridging and even in Swift when casting [1, 2, 3] as [Any]
For UInt family providing Kotlin-like wrappers seems for me to be the right default.
I have few experience with Java, but with other languages it was a pain dealing with absence of correct representation of natively unsupported types:
- partly unavailable API can block adoption or force to invent and maintain own shims
- annotations only say that there can by negative values in runtime, which are hard to resolve, sometimes making impossible to use function or at best force to provide meaningful error handling.
It will be unfortunate to have problems of this kind using modern statically-checked type-safe Swift. - widening can be a good option for part of users, e.g. when for most of code base all integers up to UInt32 are ok, and only UInt64 should be treated accurately and can be additionally annotated to warn users.
For solution with wrappers two variants of functions can be provided. One with UInt wrapper and another with unsigned integers.
This way convenient and safe API is used by default, and in performance sensitive code they can fallback to unsafe variant.