[swift-users] String initializers and developer ergonomics

[Austin Zheng]

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 at swift.org> wrote:

>
> On May 9, 2016, at 10:28 AM, Jacob Bandes-Storch via swift-users <
> swift-users at swift.org> wrote:
>
> 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
>
>
> +1
>
>  - Daniel
>
>
>
>>
>> -Joe
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
> _______________________________________________
> 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/d3a03a82/attachment.html>