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

[Max Moiseev]

> It would be nice to get some feedback from someone at Apple as to why fromCString() was implemented as a type method instead of a failable initializer. Presumably it was because there is both a repairing and a failable, non-repairing version. 

There probably were no failable initializers when it was first implemented. The other thing is `fromCStringRepairingIllFormedUTF8` returns a tuple, so cannot be an initializer.

> On Jan 12, 2016, at 11:18 AM, Charles Kissinger via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It would be nice to get some feedback from someone at Apple as to why fromCString() was implemented as a type method instead of a failable initializer. Presumably it was because there is both a repairing and a failable, non-repairing version. 
> 
>> ## Detailed design
>> 
>> See [full
>> implementation](https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units).
>> 
>> This is a fairly straightforward renaming of the internal APIs.
>> 
>> The initializer, its labels, and their order were chosen to match other
>> non-cast
>> initializers in the stdlib. "Sequence" was removed, as it was a
>> misnomer.
>> "input" was kept as a generic name in order to allow for future
>> refinements.
>> 
>> The static initializer made the same changes, but was otherwise kept as
>> a
>> factory function due to its multiple return values.
>> 
>> `String.Type._fromWellFormedCodeUnitSequence(_:input:)` was kept as-is
>> for
>> internal use. I assume it wouldn't be good to expose publicly because,
>> for
>> lack of a better phrase, we only "trust" the stdlib to accurately know
>> the
>> wellformedness of their code units. Since it is a simple call through,
>> its
>> use could be elided throughout the stdlib.
>> 
>> ## Impact on existing code
>> 
>> This is an additive change to the API.
>> 
>> ## Alternatives considered
>> 
>> * A protocol-oriented API.
>> 
>> Some kind of `func decode<Encoding>(_:)` on `SequenceType`. It's not
>> really
>> clear this method would be related to string processing, and would
>> require
>> some kind of bounding (like `where Generator.Element:
>> UnsignedIntegerType`), but
>> that would be introducing a type bound that doesn't exist on
>> 
>> * Do nothing.
>> 
>> This seems suboptimal. For many use cases, `String` lacking this
>> constructor is
>> a limiting factor on performance for many kinds of pure-Swift
>> implementations.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160112/51ca5014/attachment.html>