# SE-0532: Optional noncopyable improvements and generalizations **URL:** \ **Category:** Proposal Reviews\ **Created:** [May 26, 2026, 11:00pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941 "2026-05-26T23:00:50Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [May 26, 2026, 11:00pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/1 "2026-05-26T23:00:50Z")
Hello, Swift community. The review of [SE-0532: `Optional` noncopyable improvements and generalizations](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0532-optional-noncopyable-improvements.md) begins now and runs through June 8th, 2026. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via either forum DM or [email](mailto:rjmccall@apple.com). When contacting me directly, please put "[SE-0532]" at the start of the subject line. ### What goes into a review? The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review: - What is your evaluation of the proposal? - Is the problem being addressed significant enough to warrant a change to Swift? - Does this proposal fit well with the feel and direction of Swift? - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? More information about the Swift evolution process is available at > [https://github.com/apple/swift-evolution/blob/main/process.md](https://github.com/apple/swift-evolution/blob/main/process.md) Thanks in advance for participating in this review. John McCall Review Manager ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [May 26, 2026, 11:38pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/2 "2026-05-26T23:38:02Z")
As in the pitch, I continue to be impressed with how well these APIs leverage recently added features. I have some nits about the naming aspect of these APIs: - As before, I worry that `insert` reads poorly particularly with the example (maybe raised during the pitch) where `Wrapped` is a collection, as it reads most naturally like one is inserting into the _wrapped_ value. I think `assign` or another variation on that would go a long way to avoiding that misreading. - It's weird that `mutate()` gives something _mutable_ but doesn't actually mutate anything. I wonder if `borrowed` and `mutable`, or just `ref` and `mutableRef` (à la `span` and `mutableSpan`) would be the superior. I'm not sure I understand the argument given in the proposal text that the "nature" of the verbs "fits quite well"—indeed, I think I'd argue that the "nature" of the verb mutate specifically fits poorly in this case. ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [May 27, 2026, 12:25am UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/3 "2026-05-27T00:25:04Z")
There has always been resistance to adding more functionality to `Result`, like `isSuccess`, or a `fold` method (recent async additions notwithstanding), because it's felt those should be more general `enum` features. This functionality _also_ seems like something that should be available to all enums, but such an approach isn't even mentioned as an alternative _or_ future direction. So while this functionality seems necessary, it seems best to make it available to all enums in some way. Otherwise we'll have to use something like [`swift-case-paths`](https://github.com/pointfreeco/swift-case-paths) to synthesize imitation versions of these, if that's even possible. Personally, I'd also like something more ergonomic, though I suppose we can see how popular these APIs are and make them more ergonomic later. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [May 27, 2026, 12:40am UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/4 "2026-05-27T00:40:23Z")
I’m not sure I understand which of these changes you feel would be covered by generic support on all enums. I think you might be arguing that `map` could be a generic enum-homomorphism in the same way that `fold` could be a generic enum-catamorphism? But I honestly can’t remember anyone ever arguing that we shouldn’t add a `fold` to `Result` because we might add generic catamorphisms to all enums. I mean, other than the generic catamorphisms on enums we already have via `switch` expressions. ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [May 27, 2026, 12:58am UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/5 "2026-05-27T00:58:43Z")
Sorry, wouldn't the access patterns outlined in the Motivation apply to all enums with associated values, except one layer removed? It would require case accessors, but wouldn't I need something like `result.success.borrow()` to borrow the success value out of a `Result`? Or is the thought that this can just be generalized in terms of `Optional` directly? Or have I misunderstood the purpose of these APIs? And my mention of `fold` was simply an example generalizable API. I think I had it or something like it in the original `Result` proposal that was subsequently removed, but it was really just an example. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [May 27, 2026, 1:32am UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/6 "2026-05-27T01:32:08Z")
Ah, thanks, I can see the argument for how `borrow`/`mutate` could be construed as case accessors of `some`. ---
**Author:** ![Alejandro](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro/32/46197_2.png) [@Alejandro](https://forums.swift.org/u/Alejandro)\ **Post date:** [May 27, 2026, 5:19pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/7 "2026-05-27T17:19:14Z")
> [@xwu](#): > > As before, I worry that `insert` reads poorly particularly with the example (maybe raised during the pitch) where `Wrapped` is a collection, as it reads most naturally like one is inserting into the _wrapped_ value. I think `assign` or another variation on that would go a long way to avoiding that misreading. The example is probably poor given the wrapped type. @benlings suggested `put` as the opposite of `take` which I quite like. > [@xwu](#): > > It's weird that `mutate()` gives something _mutable_ but doesn't actually mutate anything. I wonder if `borrowed` and `mutable`, or just `ref` and `mutableRef` (à la `span` and `mutableSpan`) would be the superior. I'm not sure I understand the argument given in the proposal text that the "nature" of the verbs "fits quite well"—indeed, I think I'd argue that the "nature" of the verb mutate specifically fits poorly in this case. One of the reasons why I opted not for computed variables for these like `span` and `mutableSpan` is that these have the chance for "failure" by returning `nil` for empty optionals unlike the span accessors which can never "fail" even if the array is empty. ---
**Author:** ![Alejandro](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro/32/46197_2.png) [@Alejandro](https://forums.swift.org/u/Alejandro)\ **Post date:** [May 27, 2026, 5:28pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/8 "2026-05-27T17:28:30Z")
> [@Jon\_Shier](#): > > Sorry, wouldn't the access patterns outlined in the Motivation apply to all enums with associated values, except one layer removed? It would require case accessors, but wouldn't I need something like `result.success.borrow()` to borrow the success value out of a `Result`? Or is the thought that this can just be generalized in terms of `Optional` directly? I think we definitely want some language feature here that broadly solves this for all enums. Something akin to the following: ```swift if case .success(borrow x) = result { // ok we're borrowing the success value x.performSomeMethod() } // result is still usable here if case .success(inout x) = result { // ok we can directly mutate the success value in result x += 1 } // result is still usable here ``` Generally speaking, this `borrow x` is only valid for that tight scope. Certain enum layouts require us to temporarily destroy the enum value itself in order to get a direct reference to payload contents which means this language feature can never return the reference to an arbitrary enum payload out of this scope: ```swift func something(x: borrowing SomeComplicatedEnum) -> ??? { guard case .myCase(borrow y) = x else { return } // ok I can use 'y' here which is borrowing the payload // in 'x'. // error: can't return 'y'. // we must cleanup the 'y' reference and build 'x' back return y } ``` `Optional`, however, has a special layout that allows us to project this reference without destroying the optional value itself allowing us to return this reference out without having to perform any cleanup of the enum value: ```swift func something(x: borrowing Atomic?) -> Ref>? { x.borrow() } ``` ---
**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\ **Post date:** [May 28, 2026, 1:43am UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/9 "2026-05-28T01:43:42Z")
If we don't want to go the "Optional as a collection" route of naming the operation `insert`, we could always use `set`, `store`, or `put`. While non-destructive pattern matching is a nice feature to have, I don't think it's a problem to give `Optional` a special case implementation given that it's apparently not straight forward to generalize. ---
**Author:** ![ellie20](https://avatars.discourse-cdn.com/v4/letter/e/6f9a4e/32.png) [@ellie20](https://forums.swift.org/u/ellie20)\ **Post date:** [June 3, 2026, 4:46pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/10 "2026-06-03T16:46:04Z")
I'm unsure whether it's ideal to encourage the use of `Optional` and `Optional`, or if it would be better to have specific `OptionalRef` and `OptionalMutableRef` types that avoid the use of first-class references. I think the latter could have ergonomic benefits, such as a more consistent API with `borrowing Optional` and `inout Optional` respectively, and possibly implicit conversions between different `Optional` representations (such as from `inout Optional` to `OptionalMutableRef`) which could maybe alleviate the burden of manually considering such representation changes. In the C++ community, there is some demand for "optional references", which would be a version of `std::optional` that uses C++ references, which are analogously second-class and don't require explicit dereferencing, instead of pointers. I think such demand is likely at least in part because of the inconvenience of explicit dereferencing. I think Swift is alike to C++ in that it often uses the equivalent of C++ references to avoid first-class reference types (such as with `borrowing` and `inout` parameters), and "optional references" would be consistent with this trend. On the other hand, Rust pervasively uses first-class reference types, but requires `Deref` coercion to make this ergonomic, which has its own downsides. It would be unfortunate, I think, if Swift had to adopt those downsides while _also_ having features to avoid first-class references in the majority of situations where `Deref` coercion would be useful. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [June 3, 2026, 5:17pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/11 "2026-06-03T17:17:59Z")
`inout Optional` =\> `Optional` is a lossy conversion, and frankly somewhat semantically weird. We are generally trying to avoid adding more implicit conversions to Swift, but even if we weren't, I think that in particular wouldn't be a good idea. > [@ellie20](#): > > In the C++ community, there is some demand for "optional references", which would be a version of `std::optional` that uses C++ references, which are analogously second-class and don't require explicit dereferencing, instead of pointers. That seems to be driven by very C++-specific concerns. People want an optional type that can carry a reference because `std::optional` directly forbids carrying references because of the often surprising semantics that arise from abstraction over references in C++. (For example, assigning one `std::optional` over another would simply replace the reference value in the destination _unless_ both optionals are present, in which case it would assign the underlying values.) That is not how `Ref`s works, very intentionally. ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [June 3, 2026, 6:19pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/12 "2026-06-03T18:19:18Z")
I’ve been wondering for a while why `{Mutable}Ref` was introduced if `inout` and `borrow` bindings were still on the table… why not commit to implementing those first and allow functions to return `borrow T`? I concluded that there must be a reason why new nominal value types were preferred, and it sounds like that reason might be “C++ tried it the other way and it’s miserable?” ---
**Author:** ![Alejandro](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro/32/46197_2.png) [@Alejandro](https://forums.swift.org/u/Alejandro)\ **Post date:** [June 3, 2026, 7:49pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/13 "2026-06-03T19:49:32Z")
> [@ksluder](#): > > I’ve been wondering for a while why `{Mutable}Ref` was introduced if `inout` and `borrow` bindings were still on the table… why not commit to implementing those first and allow functions to return `borrow T`? Because returning `borrow T` is not a binding, it is still a regular type in the type system. So implementing bindings first wouldn't have solved the return `borrow`/`inout` problem. Instead of returning `borrow T` we've just gone in the direction of giving these actual names `Ref` (like `Span`) which is the same thing. ---
**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\ **Post date:** [June 3, 2026, 8:21pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/14 "2026-06-03T20:21:24Z")
C++26 has optional\ and IIRC assignment only rebinds, and you need to dereference it to mutate the referenced object. The reason this wasn't already in place was due to internal politics in WG21, and not through any real technical objection. boost::optional already supported references before it was even proposed for standardization. The alternative design where assigning to the optional potentially assigns through the reference is not a realistic design, and has never been used in any production system. The big reason optional references are attractive in C++ is because 1) references are the only naturally non-null pointer-like type in C++ and 2) C++ uses references everywhere. Neither of these are true in Swift. The only reason to use Optional\ is in Swift is to return shared access to a value that may or may not be present. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [June 3, 2026, 8:42pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/15 "2026-06-03T20:42:01Z")
I mean, I agree that that “unrealistic design” would be a bad choice, but it’s what the STL does for several existing types which you specialize them with references. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [June 30, 2026, 9:44pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/16 "2026-06-30T21:44:39Z")
Hello, Swift community. The LSG met to discuss this proposal. Feedback has generally been positive. I'd like to discuss three issues raised during the review. The first issue is about the naming of the `insert` operation, which is essentially just the ordinary assignment operator (`=`) but taking a non-optional `Wrapped` and returning a `MutableRef`. Feedback suggests that `insert` is not a great name for this, and the LSG agrees. We note several possible names for this: - `insert` (as previously proposed, which comes from Rust, but which the author has wavered on) - `put` (currently favored by the author) - `assign` (suggested earlier in the review thread) - `update` (has some precedent in the Swift standard library, e.g. on the `UnsafePointer` types) The author has chosen to propose `put` as the new name for this operation. The LSG considers this an open question and welcomes feedback on any of these alternatives. The second is about the inclusion of the `borrow()` and `mutate()` functions, which one could consider to be accessors for the payload of the `some` case. The LSG has previously indicated that it is reluctant to add general features around case accessors without a broader vision for these kinds of ad hoc pattern-matching-adjacent features in Swift. However, the LSG sees `Optional` as a special case and has no concerns about adding narrowly-tailored features around it. The third is specifically about the naming of `borrow()` and `mutate()`. The LSG sees these as analogous to `span` and `mutableSpan` and believes they ought to be properties. We have asked the author to name these properties `ref` and `mutableRef`. The LSG has decided to accept SE-0532 in principle but is extending the review until July 6th to discuss the naming of (1) the `put` operation and (2) the `ref` and `mutableRef` properties. You can see the exact changes made in this revision [here](https://github.com/swiftlang/swift-evolution/commit/82b0fff54ae1159f82eefcc69bd71c615ccd158e). John McCall Review Manager ---
**Author:** ![glessard](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/glessard/32/409_2.png) [@glessard](https://forums.swift.org/u/glessard)\ **Post date:** [July 2, 2026, 9:02pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/17 "2026-07-02T21:02:44Z")
The operation formerly known as `insert` defies attempts to name it, because it does two things. It updates the `Optional`, but it is the fact that it also returns the reference that makes the operation useful. Can we find a name that emphasizes the returned value? Until then all the names are similarly unsatisfactory. Among unsatisfactory names I would pick the most precedented one in our stdlib, `update`. ---
**Author:** ![benrimmington](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benrimmington/32/695_2.png) [@benrimmington](https://forums.swift.org/u/benrimmington)\ **Post date:** [July 3, 2026, 3:00pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/18 "2026-07-03T15:00:34Z")
> [@John\_McCall](#): > > The author has chosen to propose `put` as the new name for this operation. The LSG considers this an open question and welcomes feedback on any of these alternatives. Would `bind()` or `bind(to:)` make sense? (I think a previous proposal described `MutableRef` as a "reference binding", but I could be mistaken.) ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [July 3, 2026, 7:06pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/19 "2026-07-03T19:06:07Z")
> [@glessard](#): > > The operation formerly known as `insert` defies attempts to name it, because it does two things. It updates the `Optional`, but it is the fact that it also returns the reference that makes the operation useful. Can we find a name that emphasizes the returned value? Yeah, this is the inherent problem with an API that has side effects _and_ returns a value colliding with Swift's API naming guidelines. We like value-returning functions to be named with a noun phrase that describes the value, so an active verb like `insert` or `put` risks not communicating that it's actually return something (and the thing it returns is the whole reason you want to use it). If you forget to assign the return value, you'll get a warning _that_ you've dropped the return value, but nothing that describes _what_ it is. After thinking about this some more, the best I could come up with was taking advantage of a double-meaning, `Optional.binding(T)`: - `binding` (noun): the value being returned is a binding to the wrapped value - `binding` (verb): the `Optional`'s wrapped value is being bound to the argument I can convince myself of the noun interpretation, but the verb interpretation feels shakier. We could go really verbose—`binding(afterAssigning:)`—but that just feels like adding more words without an equally large leap in comprehension. ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [July 3, 2026, 7:17pm UTC](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941/20 "2026-07-03T19:17:40Z")
`binding` certainly feels the closest so far, and the bare `binding(_ value: Wrapped)` is pretty close to the verb form. We could do something like `binding(assigning value: Wrapped)`, which expands the noun form to be a bit more specific, relying on `assigning` to carry the verb and tense. Or going a bit more verbose, `binding(fromAssigning value: Wrapped)`. If we wanted we could also move away from the general `binding` term and use something like `mutableRef(fromAssigning value: Wrapped)`, which is pretty precise, if inelegant. [Next page](https://forums.swift.org/t/se-0532-optional-noncopyable-improvements-and-generalizations/86941.md?page=2)