# String initializers and developer ergonomics

**URL:** <https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507>\
**Category:** Using Swift\
**Created:** [May 7, 2016, 5:39pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507 "2016-05-07T17:39:24Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\
**Post date:** [May 7, 2016, 5:39pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/1 "2016-05-07T17:39:24Z")

</div>

Hello Swift users,

I wanted to run something past you folks and get some opinions/feedback.

About a month ago on Hacker News I saw someone commenting about how Swift's string-handling code was unbearably slow (3 seconds to run a code sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged. Unfortunately, I didn't have time to dig into it until this morning. The code in its entirety can be found here: [stringperf.swift · GitHub](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)

At line 26 we have the following code:

result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))

'cs' is a UTF16 view into an input string, while 'result' is a [String]. When I profiled the code in Instruments, I noticed that it was spending significant time within the reflection machinery.

It turns out that the initializer to make a String out of a utf16 view looks like this, and I believe this is the initializer the author intended to call:

init?(\_: String.UTF16View) \<\>

However, the actual initializer being called was this String initializer in the Mirror code:

public init\<Subject\>(\_ instance: Subject)

This seems like a tricky gotcha for developers who aren't extremely familiar with both the String and reflection APIs. His code looked reasonable at a first glance and I didn't suspect anything was wrong until I profiled it. Even so, I only made the connection because I recognized the name of the standard library function from poking around inside the source files.

What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.

Best,  
Austin

---

<div class="post-metadata">

**Author:** ![Dennis\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/d/4491bb/32.png) [@Dennis\_Weissmann](https://forums.swift.org/u/Dennis_Weissmann)\
**Post date:** [May 7, 2016, 10:46pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/2 "2016-05-07T22:46:09Z")

</div>

Hi Austin,

I further “swiftyfied” the code to this (swift-DEVELOPMENT-SNAPSHOT-2016-05-03-a):

import Foundation

let N = 1\_000\_000

func generateTestData() -\> [String] {  
&nbsp;&nbsp;return (0..\<N).map { \_ in ",,abc, 123 ,x, , more more more,\u{A0}and yet more, " }  
}

func splitAndTrim(s: String, sep: Character) -\> [String] {  
&nbsp;&nbsp;return s.characters.split(separator: sep, omittingEmptySubsequences: false)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.map(String.init)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.map { $0.trimmingCharacters(in: .whitespacesAndNewlines()) }  
}

func doSplits(data: [String]) -\> Int {  
&nbsp;&nbsp;return data.reduce(0) { $0 + splitAndTrim(s: $1, sep: Character(",")).count }  
}

let data = generateTestData()  
let start = NSDate()  
let sum = doSplits(data: data)  
print("elapsed: \(NSDate().timeIntervalSince(start))")  
print("sum: \(sum)")

I didn’t expect it to run as fast as the original (or even faster) but the code above takes 13 seconds to run… But that’s just an aside :)

To actually come back to the problem you mentioned:

You can disambiguate the initializer to call in the following ways (probably there are other ways):

Add an ! after the init call since the one which should be used is failable (the one that uses reflection does not), so the compiler chooses the “right” one.

result.append(begin == eos ? "" : String(cs[begin..\<end.successor()])!)

Or you can reference the initializer and use it afterwards (more future-proof):

let utf16View = cs[begin..\<end.successor()]  
let initializer = String.init as (String.UTF16View -\> String?)  
result.append(begin == eos ? "" : initializer(utf16View)!)

This reduces the time to 2.2 seconds on my machine (from ~2.9), but that’s still far from 0.8.

> What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.

It might be very surprising behavior and we could think about adding an external label to all those initializers that cause trouble. The performance is of course a little worrying for a zero-cost abstractions language, but I think there are currently more important goals (getting the design right, etc.). We are still at the early stages with a lot of stuff changing and I think when the syntax, ABI, etc. are settled, performance / optimization will get more attention :)

- Dennis

> **···**
>
> > On May 7, 2016, at 7:39 PM, Austin Zheng via swift-users \<swift-users@swift.org\> wrote:
> > 
> > Hello Swift users,
> > 
> > I wanted to run something past you folks and get some opinions/feedback.
> > 
> > About a month ago on Hacker News I saw someone commenting about how Swift's string-handling code was unbearably slow (3 seconds to run a code sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged. Unfortunately, I didn't have time to dig into it until this morning. The code in its entirety can be found here: [stringperf.swift · GitHub](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)
> > 
> > At line 26 we have the following code:
> > 
> > result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))
> > 
> > 'cs' is a UTF16 view into an input string, while 'result' is a [String]. When I profiled the code in Instruments, I noticed that it was spending significant time within the reflection machinery.
> > 
> > It turns out that the initializer to make a String out of a utf16 view looks like this, and I believe this is the initializer the author intended to call:
> > 
> > init?(\_: String.UTF16View) \<\>
> > 
> > However, the actual initializer being called was this String initializer in the Mirror code:
> > 
> > public init\<Subject\>(\_ instance: Subject)
> > 
> > This seems like a tricky gotcha for developers who aren't extremely familiar with both the String and reflection APIs. His code looked reasonable at a first glance and I didn't suspect anything was wrong until I profiled it. Even so, I only made the connection because I recognized the name of the standard library function from poking around inside the source files.
> > 
> > What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.
> > 
> > Best,  
> > Austin
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)

---

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [May 9, 2016, 5:25pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/3 "2016-05-09T17:25:27Z")

</div>

This definitely strikes me as a problem. The String\<T\>(\_:) constructor is very easy to call by accident if you're trying to hit another unlabeled initializer. It also strikes me as not particularly "value-preserving", since stringifying many types loses information. Perhaps we should propose giving it a label, String(printing:) maybe?

-Joe

> **···**
>
> > On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users \<swift-users@swift.org\> wrote:
> > 
> > Hello Swift users,
> > 
> > I wanted to run something past you folks and get some opinions/feedback.
> > 
> > About a month ago on Hacker News I saw someone commenting about how Swift's string-handling code was unbearably slow (3 seconds to run a code sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged. Unfortunately, I didn't have time to dig into it until this morning. The code in its entirety can be found here: [stringperf.swift · GitHub](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)
> > 
> > At line 26 we have the following code:
> > 
> > result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))
> > 
> > 'cs' is a UTF16 view into an input string, while 'result' is a [String]. When I profiled the code in Instruments, I noticed that it was spending significant time within the reflection machinery.
> > 
> > It turns out that the initializer to make a String out of a utf16 view looks like this, and I believe this is the initializer the author intended to call:
> > 
> > init?(\_: String.UTF16View)
> > 
> > However, the actual initializer being called was this String initializer in the Mirror code:
> > 
> > public init\<Subject\>(\_ instance: Subject)
> > 
> > This seems like a tricky gotcha for developers who aren't extremely familiar with both the String and reflection APIs. His code looked reasonable at a first glance and I didn't suspect anything was wrong until I profiled it. Even so, I only made the connection because I recognized the name of the standard library function from poking around inside the source files.
> > 
> > What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.

---

<div class="post-metadata">

**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\
**Post date:** [May 9, 2016, 5:28pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/4 "2016-05-09T17:28:24Z")

</div>

> \>  
> \> Hello Swift users,  
> \>  
> \> I wanted to run something past you folks and get some opinions/feedback.  
> \>  
> \> About a month ago on Hacker News I saw someone commenting about how  
> Swift's string-handling code was unbearably slow (3 seconds to run a code  
> sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged.  
> Unfortunately, I didn't have time to dig into it until this morning. The  
> code in its entirety can be found here:  
> [https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)  
> \>  
> \> At line 26 we have the following code:  
> \>  
> \> result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))  
> \>  
> \> 'cs' is a UTF16 view into an input string, while 'result' is a [String].  
> When I profiled the code in Instruments, I noticed that it was spending  
> significant time within the reflection machinery.  
> \>  
> \> It turns out that the initializer to make a String out of a utf16 view  
> looks like this, and I believe this is the initializer the author intended  
> to call:  
> \>  
> \> init?(\_: String.UTF16View)  
> \>  
> \> However, the actual initializer being called was this String initializer  
> in the Mirror code:  
> \>  
> \> public init\<Subject\>(\_ instance: Subject)  
> \>  
> \> This seems like a tricky gotcha for developers who aren't extremely  
> familiar with both the String and reflection APIs. His code looked  
> reasonable at a first glance and I didn't suspect anything was wrong until  
> I profiled it. Even so, I only made the connection because I recognized the  
> name of the standard library function from poking around inside the source  
> files.  
> \>  
> \> What do other people think? Is this something worth worrying about, or  
> is it so rare that it shouldn't matter? Also, any suggestions as to how  
> that code sample might be improved would be appreciated - my naive first  
> attempt wasn't any better.
> 
> This definitely strikes me as a problem. The String\<T\>(\_:) constructor is  
> very easy to call by accident if you're trying to hit another unlabeled  
> initializer. It also strikes me as not particularly "value-preserving",  
> since stringifying many types loses information. Perhaps we should propose  
> giving it a label, String(printing:) maybe?

+1

> **···**
>
> On Mon, May 9, 2016 at 10:25 AM, Joe Groff via swift-users \< swift-users@swift.org\> wrote:
> 
> > \> On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users \< \> swift-users@swift.org\> wrote:
> 
> > -Joe  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)

---

<div class="post-metadata">

**Author:** ![zwaldowski](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zwaldowski/32/21801_2.png) [@zwaldowski](https://forums.swift.org/u/zwaldowski)\
**Post date:** [May 9, 2016, 5:28pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/5 "2016-05-09T17:28:30Z")

</div>

I've been wondering about this since String(reflecting:) came about, as  
plain print() is capable of doing about the same amount of reflection as  
debugPrint(). I don't want to get into the bikeshedding of it, but I'd  
really like to see printing String initializer get a verb label. It's  
pretty strongly against the API guidelines for initializers.

Sincerely,  
Zachary Waldowski  
zach@waldowski.me

> **···**
>
> On Mon, May 9, 2016, at 01:25 PM, Joe Groff via swift-users wrote:
> 
> > This definitely strikes me as a problem. The String\<T\>(\_:) constructor is  
> > very easy to call by accident if you're trying to hit another unlabeled  
> > initializer. It also strikes me as not particularly "value-preserving",  
> > since stringifying many types loses information. Perhaps we should  
> > propose giving it a label, String(printing:) maybe?

---

<div class="post-metadata">

**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\
**Post date:** [May 10, 2016, 3:02am UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/6 "2016-05-10T03:02:36Z")

</div>

I agree, +1.

-Chris

> **···**
>
> On May 9, 2016, at 10:25 AM, Joe Groff via swift-users \<swift-users@swift.org\> wrote:
> 
> > > This seems like a tricky gotcha for developers who aren't extremely familiar with both the String and reflection APIs. His code looked reasonable at a first glance and I didn't suspect anything was wrong until I profiled it. Even so, I only made the connection because I recognized the name of the standard library function from poking around inside the source files.
> > > 
> > > What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.
> > 
> > This definitely strikes me as a problem. The String\<T\>(\_:) constructor is very easy to call by accident if you're trying to hit another unlabeled initializer. It also strikes me as not particularly "value-preserving", since stringifying many types loses information. Perhaps we should propose giving it a label, String(printing:) maybe?

---

<div class="post-metadata">

**Author:** ![ddunbar](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ddunbar/32/1933_2.png) [@ddunbar](https://forums.swift.org/u/ddunbar)\
**Post date:** [May 9, 2016, 5:54pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/7 "2016-05-09T17:54:54Z")

</div>

> \>  
> \> Hello Swift users,  
> \>  
> \> I wanted to run something past you folks and get some opinions/feedback.  
> \>  
> \> About a month ago on Hacker News I saw someone commenting about how Swift's string-handling code was unbearably slow (3 seconds to run a code sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged. Unfortunately, I didn't have time to dig into it until this morning. The code in its entirety can be found here: [stringperf.swift · GitHub](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)  
> \>  
> \> At line 26 we have the following code:  
> \>  
> \> result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))  
> \>  
> \> 'cs' is a UTF16 view into an input string, while 'result' is a [String]. When I profiled the code in Instruments, I noticed that it was spending significant time within the reflection machinery.  
> \>  
> \> It turns out that the initializer to make a String out of a utf16 view looks like this, and I believe this is the initializer the author intended to call:  
> \>  
> \> init?(\_: String.UTF16View)  
> \>  
> \> However, the actual initializer being called was this String initializer in the Mirror code:  
> \>  
> \> public init\<Subject\>(\_ instance: Subject)  
> \>  
> \> This seems like a tricky gotcha for developers who aren't extremely familiar with both the String and reflection APIs. His code looked reasonable at a first glance and I didn't suspect anything was wrong until I profiled it. Even so, I only made the connection because I recognized the name of the standard library function from poking around inside the source files.  
> \>  
> \> What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.
> 
> This definitely strikes me as a problem. The String\<T\>(\_:) constructor is very easy to call by accident if you're trying to hit another unlabeled initializer. It also strikes me as not particularly "value-preserving", since stringifying many types loses information. Perhaps we should propose giving it a label, String(printing:) maybe?
> 
> +1

+1

- Daniel

> **···**
>
> > On May 9, 2016, at 10:28 AM, Jacob Bandes-Storch via swift-users \<swift-users@swift.org\> wrote:  
> > On Mon, May 9, 2016 at 10:25 AM, Joe Groff via swift-users \<swift-users@swift.org \<mailto:swift-users@swift.org\>\> wrote:  
> > \> On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users \<swift-users@swift.org \<mailto:swift-users@swift.org\>\> wrote:
> 
> > -Joe  
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org \<mailto:swift-users@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)

---

<div class="post-metadata">

**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\
**Post date:** [May 9, 2016, 6:43pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/8 "2016-05-09T18:43:06Z")

</div>

Thanks to all who commented. I'll put together a proposal to rename that  
initializer tonight, unless someone else wants to do it. This seems like a  
pretty straightforward clarity gain, and it might even help a bit with  
compilation times.

Austin

> **···**
>
> On Mon, May 9, 2016 at 10:54 AM, Daniel Dunbar via swift-users \< swift-users@swift.org\> wrote:
> 
> > On May 9, 2016, at 10:28 AM, Jacob Bandes-Storch via swift-users \< \> swift-users@swift.org\> wrote:
> > 
> > On Mon, May 9, 2016 at 10:25 AM, Joe Groff via swift-users \< \> swift-users@swift.org\> wrote:
> > 
> > > \> On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users \< \>\> swift-users@swift.org\> wrote:  
> > > \>  
> > > \> Hello Swift users,  
> > > \>  
> > > \> I wanted to run something past you folks and get some opinions/feedback.  
> > > \>  
> > > \> About a month ago on Hacker News I saw someone commenting about how  
> > > Swift's string-handling code was unbearably slow (3 seconds to run a code  
> > > sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged.  
> > > Unfortunately, I didn't have time to dig into it until this morning. The  
> > > code in its entirety can be found here:  
> > > [stringperf.swift · GitHub](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)  
> > > \>  
> > > \> At line 26 we have the following code:  
> > > \>  
> > > \> result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))  
> > > \>  
> > > \> 'cs' is a UTF16 view into an input string, while 'result' is a  
> > > [String]. When I profiled the code in Instruments, I noticed that it was  
> > > spending significant time within the reflection machinery.  
> > > \>  
> > > \> It turns out that the initializer to make a String out of a utf16 view  
> > > looks like this, and I believe this is the initializer the author intended  
> > > to call:  
> > > \>  
> > > \> init?(\_: String.UTF16View)  
> > > \>  
> > > \> However, the actual initializer being called was this String  
> > > initializer in the Mirror code:  
> > > \>  
> > > \> public init\<Subject\>(\_ instance: Subject)  
> > > \>  
> > > \> This seems like a tricky gotcha for developers who aren't extremely  
> > > familiar with both the String and reflection APIs. His code looked  
> > > reasonable at a first glance and I didn't suspect anything was wrong until  
> > > I profiled it. Even so, I only made the connection because I recognized the  
> > > name of the standard library function from poking around inside the source  
> > > files.  
> > > \>  
> > > \> What do other people think? Is this something worth worrying about, or  
> > > is it so rare that it shouldn't matter? Also, any suggestions as to how  
> > > that code sample might be improved would be appreciated - my naive first  
> > > attempt wasn't any better.
> > > 
> > > This definitely strikes me as a problem. The String\<T\>(\_:) constructor is  
> > > very easy to call by accident if you're trying to hit another unlabeled  
> > > initializer. It also strikes me as not particularly "value-preserving",  
> > > since stringifying many types loses information. Perhaps we should propose  
> > > giving it a label, String(printing:) maybe?
> > 
> > +1
> > 
> > +1
> > 
> > - Daniel
> > 
> > > -Joe  
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-users mailing list  
> > > swift-users@swift.org  
> > > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [May 10, 2016, 6:56pm UTC](https://forums.swift.org/t/string-initializers-and-developer-ergonomics/2507/9 "2016-05-10T18:56:42Z")

</div>

Now that I see it, I realise I’ve run in to that a fair few times myself; I didn’t even know the string-view initialisers were failable.

I’m not sure I understand why reflection is exposed as an initialiser on String in the first place - it might make more sense as a global function.

Karl

> **···**
>
> > On 9 May 2016, at 20:43, Austin Zheng via swift-users \<swift-users@swift.org\> wrote:
> > 
> > Thanks to all who commented. I'll put together a proposal to rename that initializer tonight, unless someone else wants to do it. This seems like a pretty straightforward clarity gain, and it might even help a bit with compilation times.
> > 
> > Austin
> > 
> > On Mon, May 9, 2016 at 10:54 AM, Daniel Dunbar via swift-users \<swift-users@swift.org \<mailto:swift-users@swift.org\>\> wrote:
> > 
> > > On May 9, 2016, at 10:28 AM, Jacob Bandes-Storch via swift-users \<swift-users@swift.org \<mailto:swift-users@swift.org\>\> wrote:
> > > 
> > > On Mon, May 9, 2016 at 10:25 AM, Joe Groff via swift-users \<swift-users@swift.org \<mailto:swift-users@swift.org\>\> wrote:
> > > 
> > > \> On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users \<swift-users@swift.org \<mailto:swift-users@swift.org\>\> wrote:  
> > > \>  
> > > \> Hello Swift users,  
> > > \>  
> > > \> I wanted to run something past you folks and get some opinions/feedback.  
> > > \>  
> > > \> About a month ago on Hacker News I saw someone commenting about how Swift's string-handling code was unbearably slow (3 seconds to run a code sample, vs. 0.8 in Java). I asked him to provide the code, and he obliged. Unfortunately, I didn't have time to dig into it until this morning. The code in its entirety can be found here: [stringperf.swift · GitHub](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)  
> > > \>  
> > > \> At line 26 we have the following code:  
> > > \>  
> > > \> result.append(begin == eos ? "" : String(cs[begin..\<end.successor()]))  
> > > \>  
> > > \> 'cs' is a UTF16 view into an input string, while 'result' is a [String]. When I profiled the code in Instruments, I noticed that it was spending significant time within the reflection machinery.  
> > > \>  
> > > \> It turns out that the initializer to make a String out of a utf16 view looks like this, and I believe this is the initializer the author intended to call:  
> > > \>  
> > > \> init?(\_: String.UTF16View)  
> > > \>  
> > > \> However, the actual initializer being called was this String initializer in the Mirror code:  
> > > \>  
> > > \> public init\<Subject\>(\_ instance: Subject)  
> > > \>  
> > > \> This seems like a tricky gotcha for developers who aren't extremely familiar with both the String and reflection APIs. His code looked reasonable at a first glance and I didn't suspect anything was wrong until I profiled it. Even so, I only made the connection because I recognized the name of the standard library function from poking around inside the source files.  
> > > \>  
> > > \> What do other people think? Is this something worth worrying about, or is it so rare that it shouldn't matter? Also, any suggestions as to how that code sample might be improved would be appreciated - my naive first attempt wasn't any better.
> > > 
> > > This definitely strikes me as a problem. The String\<T\>(\_:) constructor is very easy to call by accident if you're trying to hit another unlabeled initializer. It also strikes me as not particularly "value-preserving", since stringifying many types loses information. Perhaps we should propose giving it a label, String(printing:) maybe?
> > > 
> > > +1
> > 
> > +1
> > 
> > - Daniel
> > 
> > > -Joe  
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-users mailing list  
> > > swift-users@swift.org \<mailto:swift-users@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)
> > > 
> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > > swift-users mailing list  
> > > swift-users@swift.org \<mailto:swift-users@swift.org\>  
> > > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org \<mailto:swift-users@swift.org\>  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)
> > 
> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
> > swift-users mailing list  
> > swift-users@swift.org  
> > [https://lists.swift.org/mailman/listinfo/swift-users](https://lists.swift.org/mailman/listinfo/swift-users)