<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Mar 2016, at 11:02, Carlos Rodríguez Domínguez via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Well, those proposal are more oriented towards annotating on C/Objective-C files to allow a more sophisticate import into swift. However, my proposal is to be able to directly annotate in swift, in order to fix “old-style” imports, autogenerated code, etc. Please, allow me to repeat myself, but consider the example of Core Data, in which model classes are autogenerated from a graphical model that, for instance, lacks from enums’ support. Therefore, if we use Core Data, then we can not use enums (Please, take a look at the proposal named "[swift-evolution] Promote "primitive" types to enums in extensions” in order to understand the intention of my proposal as a whole).<br class=""></div></div></blockquote><br class=""></div><div>If you can’t annotate the headers why not have a wrapper module that uses the C version of the module internally? Then anywhere that uses the original, int using version, has to explicitly import it. (For example a Sqlite module internally imports CSqlite) I don’t know if SwiftPM allows <a href="http://clang.llvm.org/docs/Modules.html#submodule-declaration" class="">explicit submodules</a> but if it does that means only your wrapper module has access to the int version.</div><div><br class=""></div><div>This seems much better than an annotation that basically only hides an imported function that you’d have to include in any project using the C library anyway.</div><div><br class=""></div><div><br class=""></div><div>— Thomas</div></body></html>