In another topic, the question of whether to adopt __shared led to the conclusion that sometimes the function author just doesn't know whether it will be beneficial. For example, general functions like map(_:) can’t know whether any particular argument benefits from being __shared.
This design proposes take and borrow keywords adorning parameters at the call site, but these keywords only serve as static assertions that the same annotation exists on the corresponding parameter declaration. Can we possibly address the first use case by enhancing the function call ABI to reflect the caller’s ownership preference? For example, a function declared func foo(param: unowned Int) could be called as foo(shared globalInt) or foo(take localInt) (*); at the ABI level, foo would take a hidden parameter that describes whether param was passed shared or take. The downside is increased code size and branchiness within foo, but this could be well worth it for significantly large value types with many members.
(*) Footnote: I still would like to advocate for keywords only at the declaration site, and replacing the call-site keywords with standard library functions move(_:), borrow(_:), etc.