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

[Alex Migicovsky]

> On Jan 12, 2016, at 12:08 PM, Max Moiseev 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. 
> 
> There probably were no failable initializers when it was first implemented. The other thing is `fromCStringRepairingIllFormedUTF8` returns a tuple, so cannot be an initializer.

Can the initializer take an inout parameter instead? Seems like it would be better to keep a consistent "initializer story."

>> 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.
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160112/81669854/attachment.html>