[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