# SE-0453: Vector, a fixed size array

**URL:** <https://forums.swift.org/t/se-0453-vector-a-fixed-size-array/76004>\
**Category:** Proposal Reviews\
**Created:** [November 14, 2024, 3:07am UTC](https://forums.swift.org/t/se-0453-vector-a-fixed-size-array/76004 "2024-11-14T03:07:39Z")\
**Posts on this page:** 1\
**Showing post:** 37

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [November 23, 2024, 2:38am UTC](https://forums.swift.org/t/se-0453-vector-a-fixed-size-array/76004/37 "2024-11-23T02:38:41Z")

</div>

> [@wes1](#):
>
> Sorry: for `Copyable` values the soft form "use parts" is just to have a wrapper or extension with a zero/default value, supporting the operation (from the client perspective) of "removing values" (by replacing with the zero value), and then once again needing to distinguish count and capacity (from the client's perspective) for non-zero values. I don't believe overlays like this on `Vector` are controversial for `Copyable` values, and they only raise the naming issue.

That would be _very_ controversial, in that Swift deliberately does not support default values for types (and in the general case a type doesn’t need to be constructible by the user at all).

> [@wes1](#):
>
> I can imagine using subscript-get for `~Copyable` values in a borrowing context

There’s no `get` (or `set`) accessor for subscripting `Vector`—the semantics of accessors necessary for supporting noncopyable elements are being [pitched separately](https://forums.swift.org/t/pitch-modify-and-read-accessors/75627).

It’s not mentioned at all in this proposal, probably for that reason, but you do make a good point that it is impossible to understand what’s going on for the purposes of proposal review without any reference to something about it.

---

_[View the full topic](https://forums.swift.org/t/se-0453-vector-a-fixed-size-array/76004)._