[swift-evolution] [Draft proposal] Faster/lower-level external String initialization
moiseev at apple.com
Fri Jan 15 12:39:22 CST 2016
I would not be too worried about `decode`, as it will be called qualified as `String.decode(_:as:)`.
After a quick discussion with @gribozavr, I think we’re ok with having String.decode(_:as:) accepting a CollectionType (with a name recommended by Charles, i.e. codeUnits) and String.decodeCString(_:as:) accepting an UnsafePointer. The difference between the two functions is significant enough to warrant different names even though, for now, one can be implemented using the other.
> 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.
> 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?
>>> 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:
>>> The code is still where it was before:
>>> Sent from my iPhone
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
More information about the swift-evolution