<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="">Oops, that first struct should be this:<div class=""><br class=""></div><div class="">struct F {<br class=""> static func makeF() -> (F?, Int)<br class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">}</div></div><br class=""></div><div class="">- Alex</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2016, at 5:25 PM, Alex Migicovsky 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I was trying to say that any tuple returning factory method can be turned into an initializer with an inout param. e.g.</div><div class=""><br class=""></div><div class="">struct F {</div><div class=""> func makeF() -> (F?, Int)</div><div class="">}</div><div class=""><br class=""></div><div class="">can be made into:</div><div class=""><br class=""></div><div class="">struct F {</div><div class=""> init?(inout result: Int) { … }</div><div class="">}</div><div class=""><br class=""></div><div class="">I think you should still be able to call an initializer like that with your `swiftApi(String(cString))` example, right? It would just be `swiftApi(String(cString, foo: &otherTupleValue). I thought the proposed alternative would look more like `swiftApi(String.fromCString(cString).0)` (I’ve lost track at this point about what the exact API proposal is, sorry).</div><div class=""><br class=""></div><div class="">With this approach every time you need to create a String you go through a String initializer—you don’t need to think if it’s a factory method or an initializer. That’s what I was trying to get at about keeping the “initializer story" consistent.<br class=""><div class=""><br class=""></div><div class="">- Alex</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 12, 2016, at 5:01 PM, Max Moiseev <<a href="mailto:moiseev@apple.com" class="">moiseev@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Alex,<div class=""><br class=""></div><div class="">If you mean that we still need to have initializers for both cases, we do. It’s just that in one of them (the repairing on) we throw away the information about whether repairs were made, which a) we don’t care in many cases and b) can still have using String.decodeCString.</div><div class=""><br class=""></div><div class="">Having an inout parameter in an initializer will break the (I think) common use case, where you get a CString from some C API, and want to call some Swift API that accepts String. I would do it like `swiftApi(String(cString))`, with inout it gets weird.</div><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">max</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 12, 2016, at 1:00 PM, Alex Migicovsky <<a href="mailto:migi@apple.com" class="">migi@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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 class="Apple-interchange-newline">On Jan 12, 2016, at 12:08 PM, Max Moiseev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><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=""><div 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></blockquote><div 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 class=""></div><div 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="">Can the initializer take an inout parameter instead? Seems like it would be better to keep a consistent "initializer story."</div><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=""><div class=""><div class=""><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 class="" 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;">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 class="" 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;"><br class="" 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;"><blockquote type="cite" class="" 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;">## 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 class="" 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;"></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=o7Sk0DkcYEKVmF-2FwdtorNst8jew9RdAB7R4AqhW99nINXovkDiCeNIL1SUuhfQ-2FWl69qJtEWLk-2Bime4yE-2BcG7PjQdG-2BoW3vGjL-2FQ3z5eQUkEvfuGtZ71-2FnyJx9H-2FqzDOPLVsgK6vOXqeksZdkZ14-2F3ZGOrHl28OvS8WkCiSoJUdfedot2gYZEyWxl3oqNGHOtGOZhhX7aZkpZ6Lqegu-2BcQ-3D-3D" alt="" width="1" height="1" border="0" style="height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""></div></blockquote><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=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=o7Sk0DkcYEKVmF-2FwdtorNjdSJCtCoKoY41JQ4hJKlPD1vqIcdmSFrIPI59B4XHUktdPkQ8r0NK5i-2FkDoKmOkmhobWh3X6Ot4wt6O-2FdLtwN-2FiaveIvnwGlCLiRN83KG-2FrKUndUYw6y-2BTBiL5AU9Fbm15p4KGi60BrL4Qi5WGpWxCoNo941hcCPmdriJYw1IXBEtLILmSnLUWySVR0-2Fy00ww-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>