[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init<T>(_: T)

[Austin Zheng]

I've submitted a swift-evolution PR with a modified version of the proposal that takes into account the feedback from the discussion participants.

If anyone is curious, the revised proposal can be found here: https://github.com/austinzheng/swift-evolution/blob/2b31df6163f5c5d1975a37e72c6996b82d61a5c6/proposals/0089-rename-string-reflection-init.md <https://github.com/austinzheng/swift-evolution/blob/2b31df6163f5c5d1975a37e72c6996b82d61a5c6/proposals/0089-rename-string-reflection-init.md>

Best,
Austin

> On May 28, 2016, at 1:08 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On May 26, 2016, at 9:40 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Some remaining open questions:
>>> 
>>> - Exactly what types should conform to ValuePreservingStringConvertible.  It seems clear that integer, floating point types, and Character can and should conform.  What other types should?
>> 
>> Like Brent mentioned, there are some types that are natural candidates, including Foundation types whose conformance could go into the overlays. NSURL, NSUUID, NSIndexPath. NSData is a borderline candidate, and probably not a good fit in the end (what encoding to use? what happens if you get the .description of a 100 MB NSData? etc). Same with NSDate. Maybe some of the CGStructs, although maybe the fact that CGFloat differs between platforms will sink that idea.
> 
> Yes, there definitely are Foundation types that could adopt this.  However, we don’t have a swift-evolution process at the moment to propose Foundation API extensions, so these would have to go through bugreporter.apple.com <http://bugreporter.apple.com/>.
> 
>>> - Do we need the ValuePreservingStringConvertible at all, or is the existing CustomStringConvertible enough?  We already have a few protocols for handling string convertibility, it would be great to avoid adding another one.
>> 
>> This is a good question.
>> 
>> Since a ValuePreservingStringConvertible is, by definition, a type that can be represented as a string in a lossless and unambiguous manner, would it be worth requiring a reverse conversion in the form of a failable initializer taking a string? Some of the proposed ValuePreservingStringConvertible types already have such functionality today. It would give the protocol a little more of a reason to exist, as well as encouraging proper conformance.
> 
> Yes, this would be really great.  Perhaps obvious, but this could/should be expressed an initializer requirement in ValuePreservingStringConvertible.
> 
> -Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/4d077eb1/attachment.html>