[swift-evolution] [swift-evolution-announce] [Review] SE-0027 Expose code unit initializers on String

Charles Kissinger crk at akkyra.com
Tue Feb 16 17:18:03 CST 2016


> On Feb 16, 2016, at 12:31 PM, Patrick Gili via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Guillaume,
> 
> Sorry, my mail client presents messages in a reverse chronological order. Charles replied with almost the same response as yours.
> 
> The proposal is somewhat confusing in this regard. It is not entirely clear that this is not intended to abuse String. However, you and Charles have explained it to me, and I'm fine.
> 
> Dave Abrahams echoed a cancern of mine though. The section discussing alternatives presents an alternative that might present a better solution to the problem. We should discuss this.

Personally, I’m not a fan of moving some cases of String initialization (or appending) into nested types (mutable versions of UTF8View and UTF16View in this case). I think it would make the interface more complex for users. Maybe I'm just not be seeing the advantages of this approach though. The proposal suggests it might be better for API maintenance, so maybe Zach can elaborate on that. 

—CK

> 
> Cheers,
> -Patrick
> 
>> On Feb 16, 2016, at 1:36 PM, Guillaume Lessard <glessard at tffenterprises.com> wrote:
>> 
>> 
>>> On 16 févr. 2016, at 06:15, Patrick Gili via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I would argue that these methods decrease the safety of a String and that they do indeed change the contract of the API design. If an application opens a truly binary file (e.g., something that was encrypted or a executable) and you initialize a String using these contents, I would argue that the String does not hold valid characters, and hence the value of the String is not a string-value.
>> 
>> How?
>> When the input is not valid unicode, these initializers either repair inconsistencies before returning a valid (perhaps gibberish) String, or fail and return nil. (In principle, bugs notwithstanding.)
>> 
>> Note that the exact same code can be invoked right now by copying bytes to a buffer, appending a zero and calling  String.fromCString(). Should that function be eliminated?
>> 
>> Cheers,
>> Guillaume Lessard
>> 
> 
> _______________________________________________
> 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