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

[Dave Abrahams]

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.

>
>
> 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