<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><span class="" style="float: none; display: inline !important;">It would be nice to get some feedback from someone at Apple as to why fromCString() was implemented as a type method instead of a failable initializer. Presumably it was because there is both a repairing and a failable, non-repairing version. </span><br class=""></blockquote><div class=""><br class=""></div><div class="">There probably were no failable initializers when it was first implemented. The other thing is `fromCStringRepairingIllFormedUTF8` returns a tuple, so cannot be an initializer.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 12, 2016, at 11:18 AM, Charles Kissinger 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=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It would be nice to get some feedback from someone at Apple as to why fromCString() was implemented as a type method instead of a failable initializer. Presumably it was because there is both a repairing and a failable, non-repairing version.<span class="Apple-converted-space"> </span></span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">## Detailed design<br class=""><br class="">See [full<br class="">implementation](<a href="https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units" class="">https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units</a>).<br class=""><br class="">This is a fairly straightforward renaming of the internal APIs.<br class=""><br class="">The initializer, its labels, and their order were chosen to match other<br class="">non-cast<br class="">initializers in the stdlib. "Sequence" was removed, as it was a<br class="">misnomer.<br class="">"input" was kept as a generic name in order to allow for future<br class="">refinements.<br class=""><br class="">The static initializer made the same changes, but was otherwise kept as<br class="">a<br class="">factory function due to its multiple return values.<br class=""><br class="">`String.Type._fromWellFormedCodeUnitSequence(_:input:)` was kept as-is<br class="">for<br class="">internal use. I assume it wouldn't be good to expose publicly because,<br class="">for<br class="">lack of a better phrase, we only "trust" the stdlib to accurately know<br class="">the<br class="">wellformedness of their code units. Since it is a simple call through,<br class="">its<br class="">use could be elided throughout the stdlib.<br class=""><br class="">## Impact on existing code<br class=""><br class="">This is an additive change to the API.<br class=""><br class="">## Alternatives considered<br class=""><br class="">* A protocol-oriented API.<br class=""><br class="">Some kind of `func decode<Encoding>(_:)` on `SequenceType`. It's not<br class="">really<br class="">clear this method would be related to string processing, and would<br class="">require<br class="">some kind of bounding (like `where Generator.Element:<br class="">UnsignedIntegerType`), but<br class="">that would be introducing a type bound that doesn't exist on<br class=""><br class="">* Do nothing.<br class=""><br class="">This seems suboptimal. For many use cases, `String` lacking this<br class="">constructor is<br class="">a limiting factor on performance for many kinds of pure-Swift<br class="">implementations.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""></body></html>