[swift-evolution] Pitch: Cross-module inlining and specialization

[Jonas B]

I find the following points in the proposal interesting:

> Within the scope of a single module, the Swift compiler performs very aggressive optimization, including full and partial specialization of generic functions, inlining, and various forms of interprocedural analysis.
> On the other hand, across module boundaries, runtime generics introduce unavoidable overhead
...
> The attribute can only be applied to public declarations. This is because the attribute only has an effect when the declaration is used from outside of the module.

If your company name is not Apple, looking at how your code base using Swift is typically going to be deployed - it’s very often going to end up in a iOS or macOS app bundle. Those bundles are deployed as one unit.
Now, in our code base (I suspect similar to many other users of swift), we have various frameworks that are not frameworks for the purpose of providing a stable ABI but rather:
* A reusable unit with a somewhat stable API, that can be shared between apps and with the wider open source community
* A mechanism for namespacing

Now I understand that this use-case is deferred for a later separate discussion, but my point here is that the name and the semantics of this attribute should be somewhat “forward-compatilble” with this use-case. “ inlinable” does not sound appropriate, because we don’t want to “inline” (in the C/C++ meaning) declarations into each usage site.
Instead we want to compile the annotated parts of -all linked modules- as one unit. Basically, for those parts, the module name would just function like a C++ namespace - an input to the symbol name mangling, and then the whole thing could be whole-module-optimized together.

This touches upon another comment someone made previously in this discussion - that access level and compiler visibility should be separate concepts. Because not just public methods, also private methods should be subject to this. 

Jonas