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 <[email protected]> wrote: > > On May 26, 2016, at 9:40 PM, Austin Zheng via swift-evolution > <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
