[swift-evolution] [Draft proposal] Faster/lower-level external String initialization

[Charles Kissinger]

It occurred to me that this proposal provides a way to efficiently initialize Strings from UTF code unit sequences, but it doesn’t provide a way to *append* code unit sequences to existing strings. String has an existing method to append Character sequences:

String.appendContentsOf<S : SequenceType where S.Generator.Element == Character>(_: S)

The equivalent for code units would presumably be:

String.appendContentsOf<S : SequenceType, Encoding: UnicodeCodecType where Encoding.CodeUnit == Input.Generator.Element>(_: S, encoding: Encoding.Type)

Is there any interest in adding that to the proposal? It would only have a lot of value if it could be implemented in a more efficient way than just calling String.Append() for each decoded Character. From looking at the code, that might not be straightforward.

—CK

> On Jan 26, 2016, at 3:14 PM, Zach Waldowski via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Since this seems to have gone quiet, and the code was already done, I've
> posted the PR to Swift itself:
> 
>   https://github.com/apple/swift/pull/1109
> 
> The existing proposal PR:
> 
>   https://github.com/apple/swift-evolution/pull/101
> 
> -- 
> Sincerely,
>   Zachary Waldowski
>   zach at waldowski.me
> 
> On Wed, Jan 20, 2016, at 06:08 PM, Zach Waldowski via swift-evolution
> wrote:
>> Thanks, Dave.
>> 
>> I definitely wasn't hard to convince on this. The change has already
>> been made to the proposal, its PR, and the pending PR to the stdlib.
>> 
>> Cheers!
>> Zach Waldowski
>> zach at waldowski.me
>> 
>> On Wed, Jan 20, 2016, at 01:23 PM, Dave Abrahams via swift-evolution
>> wrote:
>>> 
>>> on Fri Jan 15 2016, Zach Waldowski via swift-evolution
>>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
>>> 
>>>> Charles -
>>>> 
>>>> I shared the same concern, and mention them in the proposal. I thought
>>>> `decode(_:as:)` to be too simple to the point of being
>>>> non-descriptive,
>>> 
>>> The names of methods don't need to be descriptive.  It's the use-sites
>>> (and secondarily, declarations) that need to be clear.  Trying to make
>>> the names of methods descriptive by themselves just hurts readability at
>>> the use-site.
>>> 
>>> -Dave
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution