[swift-users] String initializers and developer ergonomics

[Jacob Bandes-Storch]

On Mon, May 9, 2016 at 10:25 AM, Joe Groff via swift-users <
swift-users at swift.org> wrote:

>
> > On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users <
> swift-users at 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:
> 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


>
> -Joe
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160509/8ea7848d/attachment.html>