[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init<T>(_: T)
austinzheng at gmail.com
Sat May 28 15:16:38 CDT 2016
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>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution