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

[Patrick Gili]

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.

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
>