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

[Zach Waldowski]

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.

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
>