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

[Charles Kissinger]

> On Feb 1, 2016, at 2:07 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Mon Feb 01 2016, Zach Waldowski <swift-evolution at swift.org> wrote:
> 
>> Due to the semantics of _StringCore and _StringBuffer (as far as I
>> understand them), such a method would not be more efficient than
>> creating another String with the new initializer and concatenating the
>> two, and would require more significant plumbing changes to
>> _StringBuffer.
> 
> We are very interested in making significant plumbing changes to String, FWIW.
> 

In that case, perhaps it would make sense to add String.append() for code unit sequences over the exiting plumbing just for completeness of the API, on the assumption that efficiency would come later when String gets its makeover.

—CK

>> 
>> 
>> It would be good to shop around for this proposal, though; maybe if
>> someone on the core team wants to chime in.
>> 
>> Cheers,
>> Zachary Waldowski
>> zach at waldowski.me
>> 
>> On Mon, Feb 1, 2016, at 03:07 AM, Charles Kissinger wrote:
>>> 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
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution