<div dir="ltr">Okay I understand most of that, but I still feel it’s misleading to put
`reserveCapacity()` on `CharacterView` and `UnicodeScalarView`.
`reserveCapacity()` should live in a type where its meaning matches up
with the meaning of the `.count` property, ideally the `UTF8View`.
Otherwise it should at least be removed from `CharacterView` and
`UnicodeScalarView` and only live in the parent `String` type.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 6:33 AM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div>On May 2, 2017, at 12:35 PM, Kelvin Ma via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br class="m_-6134563023666374022Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>I’m wondering why the String.CharacterView structure has a reserveCapacity(:) member?</div></div></div></blockquote><div><br></div></span><div>Because it conforms to the RangeReplaceableCollection protocol, which requires `reserveCapacity(_:)`.</div><div><br></div><div>More broadly, because you can append characters to the collection, and so you might want to pre-size it to reduce the amount of reallocating you might need to do in the future.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>And even more strangely, why String itself has the same method?<br></div></div></div></blockquote><div><br></div></span><div>Because it has duplicates of those `CharacterView` methods which don't address individual characters. (In Swift 4, it will be merged with CharacterView.)</div><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">It’s even weirder that String.UnicodeScalarView has this method, but it reserves `n` `UInt8`s of storage, instead of `n` `UInt32`s of storage.</div></div></blockquote><div><br></div></span><div>Because the views are simply different wrappers around a single underlying buffer type, which stores the string in 8-bit (if all characters are ASCII) or 16-bit (if some are non-ASCII). That means that `UnicodeScalarView` isn't backed by a UTF-32 buffer; it's backed by an ASCII or UTF-16 buffer, but it only generates and accepts indices corresponding to whole characters, not the second half of a surrogate pair.</div><div><br></div><div>Why not allocate a larger buffer anyway? Most strings use no extraplanar characters, and many strings use only ASCII characters. (Even when the user works in a non-ASCII language, strings representing code, file system paths, URLs, identifiers, localization keys, etc. are usually ASCII-only.) By reserving only `n` `UInt8`s, Swift avoids wasting memory, at the cost of sometimes having to reallocate and copy the buffer when a string contains relatively rare characters. I believe Swift doubles the buffer size on each allocation, so we're talking no more than one reallocation for a non-ASCII string and two for an extraplanar string. That's quite acceptable.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Also why String.UTF8View and String.UTF16View do not have this method, when it would make more sense for them to have it than for String itself and String.CharacterView to have it.</div></div></blockquote><br></span></div><div>Because UTF8View and UTF16View are immutable. They don't conform to RangeReplaceableCollection and cannot be used to modify the string (since you could modify them to generate an invalid string).</div><span class="HOEnZb"><font color="#888888"><br><div>
<span class="m_-6134563023666374022Apple-style-span" style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div style="font-size:12px">-- </div><div style="font-size:12px">Brent Royal-Gordon</div><div style="font-size:12px">Architechies</div></div></span>
</div>
<br></font></span></div></blockquote></div><br></div>