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.