jextract/jni: Specialization and constrained extension support#664
jextract/jni: Specialization and constrained extension support#664ktoso merged 1 commit intoswiftlang:mainfrom
Conversation
| } | ||
| } | ||
|
|
||
| public typealias FishBox = Box<Fish> |
There was a problem hiding this comment.
This triggers specialization for a new FishBox "type" on the java side 🐟
| /// even if it would otherwise be excluded by `swiftFilterExclude` configuration. | ||
| @attached(peer) | ||
| public macro JavaExport() = | ||
| #externalMacro(module: "SwiftJavaMacros", type: "JavaExportMacro") |
There was a problem hiding this comment.
Did not end up using in this PR, but this is a way to exclude "everything" and then include a specific specialization
This allows specializing types e.g. Box<T> with a typealias `FishBox =
Box<Fish>` becomes its own type in Java and gets all methods from Box
but also any methods where the `extension Box where Element == Fish {}`.
This gives Java access to previously unavailable APIs in a safe way.
Though yes it makes the type different in Java - so one may have to
convert to a Box<> sometimes etc. We may need more helper methods for
those.
For now I want to enable getting to those otherwise unavailable methods
via specialization.
Specialization is available via a typealias trigger, or via
configuration which is nice if you don't control the sources you're
trying to specialize.
| | Dictionaries: `[String: Int]`, `[K:V]` | ❌ | ✅ | | ||
| | Generic type: `struct S<T>` | ❌ | ✅ | | ||
| | Functions or properties using generic type param: `struct S<T> { func f(_: T) {} }` | ❌ | ❌ | | ||
| | Generic type specialization and conditional extensions: `struct S<T>{} extension S where T == Value {}` | ✅ | ❌ | |
There was a problem hiding this comment.
I think these are swapped.
| } | ||
|
|
||
| /// Translate a single element type for tuple results on the Java side. | ||
| private func translateTupleElementResult( |
There was a problem hiding this comment.
I deleted this function in my previous #657 . It seems like it might have slipped back in during a merge?
There was a problem hiding this comment.
Ugh seems so, I had a few long running branches -- sorry, let me remove that
| | Dictionaries: `[String: Int]`, `[K:V]` | ❌ | ✅ | | ||
| | Generic type: `struct S<T>` | ❌ | ✅ | | ||
| | Functions or properties using generic type param: `struct S<T> { func f(_: T) {} }` | ❌ | ❌ | | ||
| | Generic type specialization and conditional extensions: `struct S<T>{} extension S where T == Value {}` | ✅ | ❌ | |
There was a problem hiding this comment.
Huh indeed, thank you.
I wonder if inverse order would be preferable tbh... seems most people use jni mode nowadays 🤔
There was a problem hiding this comment.
I think FFM has a better design, but since I need Android support, I have to stick with the older approach🤣
There was a problem hiding this comment.
Yeah, that's the life we're stuck with on Android 😅
|
Thanks for review @sidepelican , added cleanups to #666 |
2 participants
This allows specializing types e.g. Box with a typealias
FishBox = Box<Fish>becomes its own type in Java and gets all methods from Box but also any methods where theextension Box where Element == Fish {}.This gives Java access to previously unavailable APIs in a safe way. Though yes it makes the type different in Java - so one may have to convert to a Box<> sometimes etc. We may need more helper methods for those.
For now I want to enable getting to those otherwise unavailable methods via specialization.
Specialization is available via a typealias trigger, or via configuration which is nice if you don't control the sources you're trying to specialize.
This partially addresses typealias support as well #338