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

[Max Moiseev]

The way I see it:
Since we are designing a new API here, I don’t see why it should not be similar in both 2.2 and 3.
I’m thinking of 2 different versions of decodeCString though: one accepting a CollectionType and another one accepting an UnsafePointer and calling strlen, since there are still cases, where the length of a cstring is unknown and it is a null-terminated one.
All the existing API’s will remain in place for Swift 2.2 but should be annotated with a deprecation attribute.

> On Jan 13, 2016, at 9:41 AM, Zach Waldowski <zach at waldowski.me> wrote:
> 
> Oh, alright!
> 
> So the complete API set would be, as I see it right now:
> * `decodeCString(_:encoding:repairingInvalidCodeUnits:)`, generic over
> both collection and codec for maximum flexibility
> * `init(cString:)`, generic over collection
> * `init?(validatingUTF8:)`, generic over collection
> 
> 2.2 (by this proposal) would also have `init(cString:)` and
> `init?(validatingUTF8:)` that take `UnsafePointer<CChar>` for
> compatibility.
> 
> Does that make sense, or should the new inits take buffer pointers?
> 
> ----
> Zach Waldowski
> zach at waldowski.me
> 
> On Wed, Jan 13, 2016, at 12:32 PM, Max Moiseev wrote:
>> 
>>> On Jan 13, 2016, at 1:14 AM, Zach Waldowski <zach at waldowski.me> wrote:
>>> 
>>> I might've mis-parsed the meaning of "'deprecation' magic". What's the
>>> best path forward in the near-term? Would `decodeCString` be the only
>>> one that becomes generic? Or, phrased differently, should there still be
>>> `UnsafePointer<CChar>`+`strlen` versions?
>> 
>> Sorry for not being clear. This is a breaking API change, and I think it would be nice of us to keep existing API in place marking it as deprecated for Swift 2.2 and later remove it in Swift 3. Here is an example[https://github.com/apple/swift/blob/master/stdlib/public/core/Index.swift#L76] of what I meant by ‘deprecation magic’.
>> 
>> 
>> max