[swift-evolution] Strings in Swift 4

[Chris Lattner]

> On Jan 20, 2017, at 2:23 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> 
>>> Still digesting, but I definitely support the goal of string processing even better than Perl.  Some random thoughts:
>>> 
>>> • 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.  
>> 
>> Interesting.  Could you offer some examples?
> 
> 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.  

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.

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:

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:

   let x = … something that returns a slice.
   foo(String(x))
   foo(String(x))

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.


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.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170122/ff7320c7/attachment.html>