[C++ interop] `SWIFT_COMPUTED_PROPERTY` imports the original function as available

[AnthonyLatsis]

Description

The macro doc suggests that the method is imported as a computed property:

/// Specifies that a specific C++ method should be imported as a computed
/// property. If this macro is specified on a getter, a getter will be
/// synthesized. If this macro is specified on a setter, both a getter and
/// setter will be synthesized.
///
/// For example:
///  ```
///    int getX() SWIFT_COMPUTED_PROPERTY;
///  ```
/// Will be imported as `var x: CInt {...}`.

In actuality a computed property is imported in addition to the method.

Reproduction

https://github.com/swiftlang/swift/blob/0775d254c773aa0dcafe7d9e89d832ad5e244b6c/test/Interop/Cxx/ergonomics/explicit-computed-properties.swift

Expected behavior

It was brought to my understanding that importing both is an expected implementation detail, but since one can actually use the imported method, we should either change the implementation to annotate it as unavailable or update the documentation to point out the actual behavior.

Environment

Swift version 6.2-dev (LLVM 017432c08540af8, Swift 9488df1)

Additional information

No response

[egorzhdan]

I'd say the compiler behavior here is compliant with the documentation comment. From user's perspective, there shouldn't be functional difference between something being imported as unavailable, or not being imported at all.

I believe there is value in importing the original method as unavailable, since it provides a very handy diagnostic should someone try to call the original method from Swift.

In many other parts of C++ interop documentation, we say that something was "not imported" when under the hood the declaration was imported as e.g. __scaryNameUnsafe(). In those contexts, "not imported" means that the declaration won't show up in code completion or generated module interfaces.

[AnthonyLatsis]

I believe there is value in importing the original method as unavailable

Last time I checked, we import the original method as unconditionally available, though. Are we tracking this issue somewhere else?