> On 29 Mar 2016, at 11:02, Carlos Rodríguez Domínguez via swift-evolution
> <[email protected]> wrote:
>
> 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).
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 explicit submodules
<http://clang.llvm.org/docs/Modules.html#submodule-declaration> but if it does
that means only your wrapper module has access to the int version.
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.
— Thomas
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
