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

Charles Kissinger crk at akkyra.com
Fri Jan 15 12:41:16 CST 2016


> On Jan 15, 2016, at 9:09 AM, Zach Waldowski <zach at waldowski.me> 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,
> so punted on the issue for now. I was going to circle back today and
> revisit it.

The only other decent alternative I’ve been able to come up with is decodeUTF(). 
-CK

> Cheers!
> Zachary Waldowski
> zach at waldowski.me
> 
> On Fri, Jan 15, 2016, at 02:09 AM, Charles Kissinger wrote:
>> Zach, Max:
>> 
>> Just a comment on the function and parameter names: decodeCString()
>> doesn’t seem right for the factory function that takes a CollectionType
>> since we aren’t passing in a null-terminated string there. Likewise, the
>> first argument to the corresponding initializer that takes a
>> CollectionType is currently called cString. Should the factory method
>> just be called decode() perhaps, and the argument to the initializer be
>> codeUnits rather than cString?
>> 
>> -CK
>> 
>>> On Jan 14, 2016, at 6:02 PM, Zachary Waldowski via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> In response to some recommendations from the Swift 3 plans, the proposed API has been made more comprehensive, and the proposal updated to fit.
>>> 
>>> The proposal is now PR'ed:
>>> 
>>>   https://github.com/apple/swift-evolution/pull/101
>>> 
>>> The code is still where it was before:
>>> 
>>>   https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
>>> 
>>> Sent from my iPhone
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 



More information about the swift-evolution mailing list