# \[Pitch\] borrow/mutate accessors, & immutable borrow, and mutating in signatures **URL:** \ **Category:** Pitches\ **Tags:** ownership, performance\ **Created:** [March 29, 2026, 5:44pm UTC](https://forums.swift.org/t/pitch-borrow-mutate-accessors-immutable-borrow-and-mutating-in-signatures/85676 "2026-03-29T17:44:37Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [April 3, 2026, 4:53pm UTC](https://forums.swift.org/t/pitch-borrow-mutate-accessors-immutable-borrow-and-mutating-in-signatures/85676/6 "2026-04-03T16:53:09Z")
> [@Arma](#): > > SE-0507 uses `return storage` without `&` inside `borrow` bodies. This pitch proposes `return &storage` instead. The issue is not just cosmetic. `borrow` accessors return a borrow already as implemented in SE-507. `&` in Swift means `inout`, not "by reference", and it would be inappropriate to use in borrow accessors. Also, `borrow` and `mutate` accessors have different ABIs and caller-facing behavior from the coroutine variants, so clients of a library must know whether an accessor is yielding or not, and it wouldn't be appropriate for the change to be completely implicit hidden in the implementation of the accessors. We have the [`borrow x` operator](https://forums.swift.org/t/selective-control-of-implicit-copying-behavior-take-borrow-and-copy-operators-noimplicitcopy/60168#p-267465-borrow-operator-2) on our roadmap as a way of explicitly stating an expression should be passed by borrow in situations where we currently implicitly copy. It is partially implemented in the `main` branch. It would be great to have help completing the implementation if you're interested. --- _[View the full topic](https://forums.swift.org/t/pitch-borrow-mutate-accessors-immutable-borrow-and-mutating-in-signatures/85676)._