# SE-0223: Accessing an Array's Uninitialized Buffer **URL:** \ **Category:** Proposal Reviews\ **Created:** [August 13, 2018, 4:47pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194 "2018-08-13T16:47:51Z")\ **Posts on this page:** 20\ **Page:** 1
**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:** [August 13, 2018, 4:47pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/1 "2018-08-13T16:47:51Z")
The review of [SE-0223: Accessing an Array's Uninitialized Buffer](https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md) begins now and runs through Wednesday, August 28th, 2018. 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 [email](mailto:jgroff@apple.com) or direct message on the forums. If you send me email, please put "SE-0223" somewhere in the subject line. **What goes into a review of a proposal?** The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When reviewing a proposal, here are some questions to consider: - 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? Thank you for contributing to Swift! Joe Groff Review Manager ---
**Author:** ![soroush](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/soroush/32/859_2.png) [@soroush](https://forums.swift.org/u/soroush)\ **Post date:** [August 14, 2018, 12:48am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/2 "2018-08-14T00:48:20Z")
- What is your evaluation of the proposal? +1. This seems like a definite performance trap in Swift. - Is the problem being addressed significant enough to warrant a change to Swift? Yes. The code change is small and the benefits are worthwhile. - Does this proposal fit well with the feel and direction of Swift? Yes. One of Swift's nicest features is its value type system. It yields code that is easier to reason about, with a tradeoff — sometimes values are copied around more than expected. This change is the best kind, because it gives us back that performance, without sacrificing the grokkable model. - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? I don't have experience with other languages at this level of depth. - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I read the pitch thread, the proposal multiple times, and the implementation PR. ---
**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\ **Post date:** [August 14, 2018, 2:03am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/3 "2018-08-14T02:03:52Z")
**What is your evaluation of the proposal?** +1. I've wanted something like this for a very long time (e.g. to implement a concurrent `map`, where values are initialised in parallel). It's also very helpful for C interop. The API seems as clear as it can be. **Is the problem being addressed significant enough to warrant a change to Swift?** Absolutely. Initialising an Array out-of-order is an important feature, but until now it's required intermediate results and copies. **Does this proposal fit well with the feel and direction of Swift?** I think the API is as clear as it could be. As for the direction of Swift - I hope a similar API comes to other types with a well-defined binary format like `String` one day. I think this kind of pattern could probably fit with String. **If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?** C++'s `std::vector` has a (mutable, contiguous) data pointer, but AFAIK it cannot be used to reinitialise contents out-of-order or in a way which changes the number of elements. **How much effort did you put into your review? A glance, a quick reading, or an in-depth study?** Participated in discussion, read draft and final proposals, have wanted something like this for years (it's not top of the list, but it's definitely on there).. ---
**Author:** ![SlaunchaMan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slaunchaman/32/520_2.png) [@SlaunchaMan](https://forums.swift.org/u/SlaunchaMan)\ **Post date:** [August 15, 2018, 3:30pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/4 "2018-08-15T15:30:21Z")
- What is your evaluation of the proposal? +1. Though I would probably find few places to use this in the user-facing iOS apps that I write on a daily basis, those places where I do need this type of performance-sensitive code would be helped by this new method. - Is the problem being addressed significant enough to warrant a change to Swift? Yes. Performance gotchas on hidden collection copies can be crippling. - Does this proposal fit well with the feel and direction of Swift? Yes. I pulled down the example code into a playground and it felt completely natural. - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? The closest example I can think of is manually creating array buffers in C. The Swift version is definitely more verbose, but comes close to the feel of directly allocating the memory in C. - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I read the proposal and downloaded the sample code into a playground, where I played with it a bit. ---
**Author:** ![Patrick\_Gili](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/patrick_gili/32/6033_2.png) [@Patrick\_Gili](https://forums.swift.org/u/Patrick_Gili)\ **Post date:** [August 15, 2018, 4:25pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/5 "2018-08-15T16:25:56Z")
> [@Joe\_Groff](#): > > - What is your evaluation of the proposal? > > +1 > > The current implementation of Array makes it difficult to implement a great number of algorithms, and the impact is usually negative. I have implementations that could have been O(1) that end up O(n) due to the need to initialize the contents of an Array to enable the algorithm random access to the underlying storage. This proposal would remove this barrier to performant implementations of these algorithms. > > - Is the problem being addressed significant enough to warrant a change to Swift? > > Yes, for the reasons I state above. > > - Does this proposal fit well with the feel and direction of Swift? > > Yes. > > - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? > > This proposal would align well with other C-family languages. > > - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? > > I studied this in-depth and read the entire thread that lead to the proposal. Response inline above. ---
**Author:** ![Braden\_Scothern](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/braden_scothern/32/1580_2.png) [@Braden\_Scothern](https://forums.swift.org/u/Braden_Scothern)\ **Post date:** [August 15, 2018, 5:44pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/6 "2018-08-15T17:44:55Z")
> [@](#): > > - What is your evaluation of the proposal? > +1 > > - Is the problem being addressed significant enough to warrant a change to Swift? > Yes it fixes a lot of performance issues with Arrays. > > - Does this proposal fit well with the feel and direction of Swift? > Yes. > > - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? > It allows Swift to match the array initialization performance of other languages that allow you to access memory directly like C and C++. > > - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? > I participated in the pitch phase, I read the final proposal, and have considered proposing this my self and just lacked the time. ---
**Author:** ![griotspeak](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/griotspeak/32/1966_2.png) [@griotspeak](https://forums.swift.org/u/griotspeak)\ **Post date:** [August 15, 2018, 9:43pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/7 "2018-08-15T21:43:10Z")
- What is your evaluation of the proposal? +1 overall from me. This would have been helpful to me a few times that I can think of offhand. - Is the problem being addressed significant enough to warrant a change to Swift? Yes - Does this proposal fit well with the feel and direction of Swift? Yes - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? I have not - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I have read the proposal. ---
**Author:** ![jawbroken](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jawbroken](https://forums.swift.org/u/jawbroken)\ **Post date:** [August 16, 2018, 1:54am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/8 "2018-08-16T01:54:01Z")
The proposed functionality is useful and much safer than the current workarounds, which require extensive use of unsafe APIs to obtain similar performance. I participated in the pitch thread and I'm very happy with how the proposal turned out. The main remaining sharp edge is the `inout initializedCount`, which is easy to misuse by forgetting to set it on some return path, but there doesn't seem to be an alternative that preserves the other useful aspects like `rethrows` (see the [pitch thread](https://forums.swift.org/t/array-initializer-with-access-to-uninitialized-buffer/13689) for details). These methods are clearly labelled as unsafe, so I think having this sharp edge is acceptable. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [August 16, 2018, 5:56pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/9 "2018-08-16T17:56:15Z")
> [@Joe\_Groff](#): > > What is your evaluation of the proposal? support! > [@Joe\_Groff](#): > > Is the problem being addressed significant enough to warrant a change to Swift? yes > [@Joe\_Groff](#): > > Does this proposal fit well with the feel and direction of Swift? in all honesty, no, but i believe it’s the best solution to a hard API-design problem, and that’s better than nothing > [@Joe\_Groff](#): > > If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? C, but C also doesn’t care about uninitialized buffers to begin with so obviously this is a step up > [@Joe\_Groff](#): > > How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Been following it and providing feedback since it was first pitched ---
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [August 20, 2018, 6:44am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/10 "2018-08-20T06:44:58Z")
> What is your evaluation of the proposal? I think it's a good design for a good idea. (I also think `String` might benefit from something like this, but that's somewhat more complicated and definitely severable.) The one thing I would criticize: I'm not sure it's a good idea to make these members rethrowing. The ["Guarantees after throwing" section](https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md#guarantees-after-throwing) reads like a hundred subtle memory safety bugs waiting to happen. _Not_ making these members rethrow would force users to stop and think about their error handling, rather than blindly writing `try` and failing to catch the bug. > Is the problem being addressed significant enough to warrant a change to Swift? Probably. There are places where I might have used this API if it had been available already. > Does this proposal fit well with the feel and direction of Swift? Yes. > If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? The most similar thing I can think of is the wonky `-[NSData initWithBytesNoCopy:length:deallocator:]` family of APIs. This approach seems vastly superior, since it doesn't complicate the management of the array's memory. > How much effort did you put into your review? A glance, a quick reading, or an in-depth study? A quick read. I didn't participate in earlier rounds of discussion. ---
**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:** [August 20, 2018, 5:30pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/11 "2018-08-20T17:30:29Z")
To everyone who contributed to this thread, thank you for your feedback! I will update this thread with the core team's decision when it happens. Meanwhile, discussion and further feedback is still welcome until final core team review happens. ---
**Author:** ![hooman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hooman/32/43536_2.png) [@hooman](https://forums.swift.org/u/hooman)\ **Post date:** [August 20, 2018, 6:12pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/12 "2018-08-20T18:12:43Z")
I am +0.5 on this. I will definitely benefit from the manual optimization opportunities enabled by this proposal, **But:** I don't feel providing such manual optimization enablers is the right approach in general. I think we need deeper redesign of the compiler and standard library to reduce such bottlenecks and make them more reliably optimizable. So, I welcome this addition, but I hope patching performance traps like this does not become the dominant approach in the language evolution. I also second @beccadax's concern about rethrowing behavior. ---
**Author:** ![jawbroken](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jawbroken](https://forums.swift.org/u/jawbroken)\ **Post date:** [August 21, 2018, 1:44am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/13 "2018-08-21T01:44:03Z")
> [@beccadax](#): > > The one thing I would criticize: I'm not sure it's a good idea to make these members rethrowing. The ["Guarantees after throwing" section](https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md#guarantees-after-throwing) reads like a hundred subtle memory safety bugs waiting to happen. _Not_ making these members rethrow would force users to stop and think about their error handling, rather than blindly writing `try` and failing to catch the bug. The problem here, pointed out in the earlier discussion threads, is that you will want to use these methods to implement `stablyPartitioned(by:)` and similar `rethrows` methods, and the only way to work around this (i.e. prove to the compiler that you will only throw if the closure is throwing) is to exploit a compiler bug. Though, now that I look more closely at the implementation of `stablyPartitioned(by:)` in the proposal, it seems like it might violate its own rules around throwing since I don't see where it deinitialises the elements if `belongsInFirstPartition` throws. Am I missing something, @nnnnnnnn? > [@hooman](#): > > I don't feel providing such manual optimization enablers is the right approach in general. I think we need deeper redesign of the compiler and standard library to reduce such bottlenecks and make them more reliably optimizable. You're going to need a fairly heroic compiler to somehow realise that the straightforward (but slow) implementation of `stablyPartitioned(by:)`, using only memory-safe APIs (e.g. filling two arrays then concatenating them), should be optimised to instead fill an array from both ends and meet at the right point in the middle. Nobody is proposing to add these methods instead of improving the optimiser, but there will always be cases that no reasonable optimisation will be able to handle. ---
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [August 21, 2018, 1:47am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/14 "2018-08-21T01:47:43Z")
Put simply: We need some kind of `withActuallyRethrowing(_:do:)` function anyway. We shouldn’t design this API in a dangerous way because that API doesn’t exist yet. ---
**Author:** ![hooman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hooman/32/43536_2.png) [@hooman](https://forums.swift.org/u/hooman)\ **Post date:** [August 21, 2018, 1:56am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/15 "2018-08-21T01:56:57Z")
> [@jawbroken](#): > > You're going to need a fairly heroic compiler... I should have put standard library first in my response. I think we can do better in the design and implementation of key currency types and protocols to improve optimizability without too frequently patching things up by enabling manual optimizations that become necessary because of the shortcomings of the current design (both at the API level and internal data structure level). I think memory-safe API can be achieved at lower cost with better design, but to get there we need to look at the whole jungle instead of focusing on individual trees. ---
**Author:** ![jawbroken](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jawbroken](https://forums.swift.org/u/jawbroken)\ **Post date:** [August 21, 2018, 1:58am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/16 "2018-08-21T01:58:53Z")
Okay, sure, but I'm not sure I see how it would be much safer. If `belongsInFirstPartition` throws inside the initialiser you're still going to need to catch the error, put memory into some reasonable state, juggle the error out of the closure and return the initialised count, then `withActuallyRethrowing` the error. So the only differences are that you've made it harder to forget to set an accurate initialised count (by presumably making it a return vale of the closure) while adding a significant complexity around handling the error, including the use of a new unsafe API with a different possible failure mode (`withActuallyRethrowing`). ---
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [August 21, 2018, 3:04am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/17 "2018-08-21T03:04:52Z")
Because you can no longer use the obvious, instinctive, and wrong solution of “just add `try` to get rid of the error”. If we could instead mark the closure so that it would need to contain a `catch` block rather than just propagating the error without additional logic, that might work too. But that would require a much larger and trickier language change. ---
**Author:** ![palimondo](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/palimondo/32/1144_2.png) [@palimondo](https://forums.swift.org/u/palimondo)\ **Post date:** [August 21, 2018, 4:20am UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/18 "2018-08-21T04:20:09Z")
This is, in my opinion, very well thought out and well written proposal that safely addresses an important performance deficit. The naming section deserves extra special kudos. Exemplary work @nnnnnnnn! ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [August 21, 2018, 5:40pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/19 "2018-08-21T17:40:05Z")
I don't have much to contribute for a formal review (which is good since it's past the formal review period), but I am also very much in favor of adding this. The times I've needed it have all been out-parameters of imported C functions, where I was forced to initialize the array elements to some dummy value before use. Which isn't _terrible_ (the value is usually zero), but still feels wrong. My one bit of discomfort is Brent's point about `rethrows`. I was previously on the "it's important for composability" side but the hypothetical future `withActuallyRethrowing` (or whatever) is a better answer to that problem. The trouble is we don't know how _far_ future that is, and therefore it may still be worth including this API with the additional sharp edges. ---
**Author:** ![ahti](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ahti/32/604_2.png) [@ahti](https://forums.swift.org/u/ahti)\ **Post date:** [August 21, 2018, 9:48pm UTC](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/20 "2018-08-21T21:48:03Z")
I haven't followed this proposal in detail, so if this doesn't make sense just ignore me: The rethrowing should only be a problem with the method, not the initializer, right? Would a potential consuming-self-attribute (plus returning self alongside the result after the access is done) help here, so that the array is not accessible if the function didn't return normally? If that's the case it may be worth holding back that part of the proposal until we have a consuming attribute, and include just the initializer in the meantime? [Next page](https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194.md?page=2)