<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jan 22, 2017, at 3:31 PM, Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2017, at 2:23 PM, Jonathan Hull 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="Singleton" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><span class=""><br class="Apple-interchange-newline">Still digesting, but I definitely support the goal of string processing even better than Perl. Some random thoughts:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">• I also like the suggestion of implicit conversion from substring slices to strings based on a subtype relationship, since I keep running into that issue when trying to use array slices. </span><br class=""></blockquote><span class=""></span><br class=""><span class="">Interesting. Could you offer some examples?</span><br class=""></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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: 12px; font-style: normal; font-variant-caps: 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="">Nothing catastrophic. Mainly just having to wrap all of my slices in Array() to actually use them, which obfuscates the purpose of my code. It also took me an embarrassingly long time to figure out that was what I had to do to make it work. For the longest time, I couldn’t understand why anyone would use slices because I couldn’t actually use them with any API… and then someone mentioned wrapping it in Array() here on Evolution and I finally got it. </div></div></div></div></blockquote><br class=""></div><div>I agree that it is important to make String[Slice] and Array[Slice] consistent. If there is an implicit conversion for one, it makes sense for their to be an implicit conversion for the other.</div><div><br class=""></div><div>That said, an implicit conversion here is something that we need to consider very carefully. Adding them would definitely increase programmer convenience in some cases, but it comes with two potentially serious costs:</div><div><br class=""></div><div>1) The conversion from a slice to a container is a copying and O(n) memory allocating operation. Swift tends to prefer keeping these sorts of operations explicit, in order to make it easier to reason about performance of code. For example, if you are forced to write:</div><div><br class=""></div><div> let x = … something that returns a slice.</div><div> foo(String(x))</div><div> foo(String(x))</div><div><br class=""></div><div>then you’re likely to notice the fact that you’re doing two expensive operations, which are redundant. If the conversion is implicit, you’d never notice. Also, the best solution may not be to create a single local temporary, it might actually be to change “foo” to take a slice.</div></div></blockquote><div><br></div>For completeness only, I should point out that we already have this situation with implicit conversion of Array<T> to Array<T?>.<div><br><blockquote type="cite"><div><div>2) Implicit conversions like this are known to slow down the type checker, sometimes substantially. I know that there are improvements planned, but this is exactly the sort of thing that increases the search space the constraint solver needs to evaluate, and it is already exponential. This sort of issue is the root cause of the embarrassing “expression too complex” errors.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></blockquote></div></body></html>