# @\_exported and fixing import visibility **URL:** \ **Category:** Discussion\ **Created:** [February 1, 2018, 4:34am UTC](https://forums.swift.org/t/exported-and-fixing-import-visibility/9415 "2018-02-01T04:34:10Z")\ **Posts on this page:** 1\ **Showing post:** 36
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [December 13, 2018, 7:37pm UTC](https://forums.swift.org/t/exported-and-fixing-import-visibility/9415/36 "2018-12-13T19:37:40Z")
> [@Joe\_Groff](#): > > Furthermore, it seems to me to be a reasonably consistent model to say that any module with a Clang backing module and an overlay gets to choose what it re-exports. (Outside the Apple ecosystem, the analog would be a swiftpm package trying to provide a Swifty interface on top of a raw Clang module.) Isn't that how it works in fact today, and it's just a matter of policy that Apple library overlays `@exported import` their underlying module? No, it isn't; only the overlays write that explicitly. A mixed-source framework always re-exports its Clang module, but _whether or not_ that was the case you'd _still_ run into issues with the example I showed, because there's a pure C module "in the middle" if the import chain. But I'm really trying to leave mixed-source frameworks out of this and just deal with "Swift libraries with C interfaces", which I think is interesting everywhere. @anandabits' model is workable, with the new restriction being on things that are both `public` and `@objc`. (I'm okay with sacrificing a bit of precision for app targets, which expose `@objc internal` things too.) It does mean the work here on "implementation imports" won't solve the problems with operators and extension members leaking out, but I do feel better knowing that Python works the same way…even if "extensions" are way less common in Python. --- _[View the full topic](https://forums.swift.org/t/exported-and-fixing-import-visibility/9415)._