# SE-0384: Importing Forward Declared Objective-C Interfaces and Protocols

**URL:** <https://forums.swift.org/t/se-0384-importing-forward-declared-objective-c-interfaces-and-protocols/62392>\
**Category:** Proposal Reviews\
**Created:** [January 4, 2023, 10:38pm UTC](https://forums.swift.org/t/se-0384-importing-forward-declared-objective-c-interfaces-and-protocols/62392 "2023-01-04T22:38:28Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![NuriAmari](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nuriamari/32/19888_2.png) [@NuriAmari](https://forums.swift.org/u/NuriAmari)\
**Post date:** [January 5, 2023, 8:37pm UTC](https://forums.swift.org/t/se-0384-importing-forward-declared-objective-c-interfaces-and-protocols/62392/9 "2023-01-05T20:37:02Z")

</div>

> [@codafi](#):
>
> I think it would make more sense to have the ClangImporter pull the types in as unavailable `typealias`es of `Any`. Parametric usages in functions would still appear as `Forward!`, and parametric usages in types as `T<Forward>`.

Could you elaborate a little on why you believe that to be a better choice? It seems to me you would be losing a considerable amount of type safety. That said, I could see the use of `Any` reducing some of the issues with LLDB conflicts.

> [@codafi](#):
>
> ```swift
> public class Bar {
> @available(*, unavailable, message: "This method references an Objective-C class 'ForwardClass' that has only been forward declared; import its owning module to use it.")
> public func foo(one: ForwardClass!, many: [ForwardClass]) {}
> }
> 
> @available(*, unavailable, message: "This extension references an Objective-C protocol 'ForwardProtocol' that has only been forward declared; import its owning module to use it.")
> extension Bar: ForwardProtocol { }
> 
> ```

Why do the users of the incomplete type need to be marked unavailable? The purpose of this proposal is to make them available from Swift, despite depending on an incomplete type.

> [@codafi](#):
>
> Overall, I appreciate the effort to try to improve the diagnostics for end users in such a common case.

If diagnostics are the primary goal of the above snippet, there is a separate effort to accomplish that which should already be reporting such issues: [[Pitch] Lazy ClangImporter Diagnostics Enabled by Default](https://forums.swift.org/t/pitch-lazy-clangimporter-diagnostics-enabled-by-default/54651)

> [@codafi](#):
>
> I'm particularly nervous about the idea that import order can affect the API surface presented to and exported by a module or file. This will have impacts on the incremental build that should be explored.

For one the API surface exported by a module or file should not be influenced by this change, since synthesized types are unavailable and thus should not escape file scope. Furthermore import order also shouldn't have an effect (REPL / LLDB aside). Please let me know if I've misunderstood something.

---

_[View the full topic](https://forums.swift.org/t/se-0384-importing-forward-declared-objective-c-interfaces-and-protocols/62392)._