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

[Zach Waldowski]

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