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

[Guillaume Lessard]

> 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