[Pitch] Controlling function definition visibility in clients

[Douglas_Gregor]

@Andrew_Trick

All we ever needed was two simple, unambiguous controls:

@export(interface)

@export(implementation)

Those can work. The equivalent to today's @inlinable would then be @export(interface, implementation), I presume?

@Joe_Groff had separately pointed out that we already have a spelling for "exported out of the module": public. We could view this as being related to access control, e.g., public(interface) and public(implementation). We might just be trading one misleading association (inlining) with another (access control).

@j-f1

@abi(none). Since this attribute only affects the ABI, adding it to the @abi attribute keeps related concerns syntactically similar.

It's more than ABI, though, and people use @inlinable (one of the things subsumed here) as a performance optimization. Overloading @abi seems like another almost-equivalence that we might regret.

@j-f1

The motivation for @inlinable(never)seems to be based around three use cases:

1. Allowing external linking. This seems better served by other language/ecosystem features, like SwiftPM/dynamic linking, public symbols, and @c @implementation. I’m don’t see how these existing features are insufficient to cover this use-case.

public doesn't necessarily mean that it's linkable externally, only that Swift code in another module can call it.

@j-f1

2. Stabilizing the public ABI across code changes. This feels better placed at the build system level (like we have today with library evolution). Manually identifying places in your code that need to be marked as non-inlinable externally seems like a recipe for extremely fragile builds. Maintaining ABI stability using library evolution mode is already quite challenging, and having to manually spell out the constraints would make it even more complex.
3. Build performance hacks. This use case feels very clearly like the responsibility of the build system to configure. For example, it could maintain a memory of which function implementation changes led to the longest incremental compiles and use that to configure the compilation process to temporarily stabilize those functions to speed up future compilation. This kind of thing would not need any sort of source-level feature to activate it and would therefore keep the source code focused on implementation rather than configuration.

I would hope that improvements to the build system [*] here would mean that the vast majority of Swift developers never need to think about these attributes, because Swift just does the right thing: expose implementations for performance when it's safe, hide them for incremental build performance, whatever. Even an excellent system is likely to make the wrong choice for some users some of the time. Having language-level controls available for users to express what they need is important for those cases.

Doug

[*] It's not just one build system, it's every build system. I deal with SwiftPM, swift-build, CMake, and Makefile-based Swift projects on a daily basis.