I'm trying to use apinotes for this third-party C library (call it "Lib.dylib"). It has an enum lgs_error_t:
typedef enum { lgs_error_none = 0, lgs_error_invalid_handle = -1, lgs_error_null = -2, lgs_error_invalid_parameter = -3, lgs_error_invalid_operation = -4, lgs_error_queue_full = -5 } lgs_error_t; So I wrote apinotes ("Lib.apinotes") that look like this, next to the .dylib, and part of my Xcode iOS app target: Enumerators: # lgs_error_t - Name: lgs_error_none SwiftName: lgs_error_t.none - Name: lgs_error_invalid_handle SwiftName: lgs_error_t.invalidHandle - Name: lgs_error_null SwiftName: lgs_error_t.nullParameter - Name: lgs_error_invalid_parameter SwiftName: lgs_error_t.invalideParameter - Name: lgs_error_invalid_operation SwiftName: lgs_error_t.invalidOperation - Name: lgs_error_queue_full SwiftName: lgs_error_t.queueFull But this line of code fails: var err: lgs_error_t = .nullParameter Type 'lgs_error_t' has no member 'nullParameter' Am I missing something else? > On May 4, 2017, at 16:55 , Douglas Gregor via swift-users > <swift-users@swift.org> wrote: > > >> On May 3, 2017, at 4:10 PM, Geordie J via swift-users >> <swift-users@swift.org> wrote: >> >> Hi everyone, >> >> I’m about to start on another big project with Swift on Android and would >> like to annotate that JNI headers as much as possible before I do: >> specifically I’d like to make _Nonnull and CF_SWIFT_NAME annotations to the >> headers found in a user's jni.h. >> >> The question is: is it possible to annotate headers this without changing >> the original header files? Specifically I’m looking for an options that >> allows annotations in a separate file, probably one that is read when >> loading the package’s module.modulemap. >> >> I’d like to distribute the annotations in a SwiftPM package that also >> exposes the original (hopefully annotated) headers. Up until now I’ve been >> using Swift to override methods in code, but this isn’t as clean or >> extensible and I fear it may have other (particularly performance) >> implications. >> >> I guess the alternative would be to just maintain and distribute a modified >> version of jni.h with the annotations, but that would be a "last resort” >> option. > > > This is the role of API notes, which you can see here: > > https://github.com/apple/swift/tree/master/apinotes > > with some rough documentation-in-source here: > > > https://github.com/apple/swift-clang/blob/stable/lib/APINotes/APINotesYAMLCompiler.cpp > > - Doug > > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users -- Rick Mann rm...@latencyzero.com _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users