<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class=""> associatedtype ExtendedASCII </div><div class=""> : BidirectionalCollection where Element == UInt32</div><div class=""> var extendedASCII: ExtendedASCII { get }</div></div></blockquote><div class=""><br class=""></div><div class="">This isn't a criticism, just a question: why constrain the collection to UInt32 elements? It seems unfortunate that the most common buffer types (UTF-16, UTF-8, or "unparsed bytes") can't just be passed as-is.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""> var unicodeScalars: UnicodeScalars { get }</blockquote></div></div><div class=""><br class=""></div><div class="">Typo: this appears twice in the Unicode protocol.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class="">We should represent these aspects as orthogonal, composable components, abstracting pattern matchers into a protocol like this one, that can allow us to define logical operations once, without introducing overloads, and massively reducing API surface area.</blockquote></div></div><div class=""><br class=""></div><div class="">I'm still uneasy about the performance of generalized matching operations built on top of Collection. I'm not sure we can reasonably expect the compiler to lower that all down to bulk memory accesses. That's at least only one part of the manifesto, though.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">clipboard.write(s.endIndex.codeUnitOffset)</div><div class="">let offset = clipboard.read(Int.self)</div><div class="">let i = String.Index(codeUnitOffset: offset)</div></div></blockquote><div class=""><br class=""></div>Sorry, what is 'clipboard'? I think I'm missing something in this section—it's talking about how it's important to have a stable representation for string positions across the different index types, but the code sample doesn't directly connect for me.<div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class="">Our support for interoperation with nul-terminated C strings is scattered and incoherent, with 6 ways to transform a C string into a String and four ways to do the inverse. These APIs should be replaced with the following</blockquote></div><div class=""><br class=""></div><div class="">This proposal doesn't plan to remove the implicit, scoped, argument-only String-to-UnsafePointer<CChar> conversion, does it? (Is that one of the 6?)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">To address this need, we can build models of the Unicode protocol that encode representation information into the type, such as NFCNormalizedUTF16String.</blockquote><br class=""></div><div class="">Not an urgent thought, but I wonder if these alternate representations really belong in the stdlib, as opposed to some auxiliary library like "SwiftStrings" or "CoreStrings", and if so whether that's still part of the standard Swift distribution or just a plain old SwiftPM package that happens to be maintained by Apple (and maybe comes preincluded with Xcode for now).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">That's all I have. Again, great work, and godspeed.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class="">(unfortunately I am not in charge of implementing any of the features you need for this, at least as far as I know)</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 19, 2017, at 18:56, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">Below is our take on a design manifesto for Strings in Swift 4 and beyond.<br class=""><br class="">Probably best read in rendered markdown on GitHub:<br class=""><a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md" class="">https://github.com/apple/swift/blob/master/docs/StringManifesto.md</a><br class=""><br class="">We’re eager to hear everyone’s thoughts.<br class=""><br class="">Regards,<br class="">Ben and Dave<br class=""></div></div></blockquote></div><br class=""></div></body></html>