on Thu May 26 2016, Austin Zheng <[email protected]> wrote: > I think this is an incredible idea. > > Should we eventually prepare an updated proposal?
I think that's what “returned for revision” implies ;-) > Given the need for further discussion I'd be happy to drive it > forward, or if someone else wants they can take over too. > > (inline) > >> On May 25, 2016, at 10:08 PM, Chris Lattner <[email protected]> wrote: >> >> Proposal Link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md >> >> The review of "SE-0089: Renaming String.init<T>(_: T)" ran from May >> 17…23, 2016. The proposal has been *returned for revision* and >> another round of discussion - the core team would love to see the >> revised proposal make it into Swift 3. >> >> The community and core team both want to remove this “footgun” from >> the standard library, where someone could write "String(x)” with the >> intention of getting a value-preserving conversion to String, but >> may instead get a potentially lossy and potentially expensive >> reflection-based conversion to a String. After extensive >> discussion, the core team recommends that the community consider a >> somewhat more elaborate design: >> >> - Rename the existing reflection-based "String.init<T>(_: T)” >> initializer to "String.init<T>(describing: T)” as recommend by the >> community. This initializer would rarely be invoked in user code >> directly. >> >> - Introduce a new protocol (for sake of discussion, call it >> “ValuePreservingStringConvertible") that refines >> CustomStringConvertible but that adds no new requirements. >> Conformance to this protocol indicates that the “description” >> requirement produces a value-preserving representation in String >> form. >> >> - Introduce a new unlabeled initializer on String: "init<T: >> ValuePreservingStringConvertible>(_ v: T) { return v.description }". >> This permits the “String(x)” syntax to be used on all values of >> types that can be converted to string in a value-preserving way. >> >> - Audit important standard library types (e.g. the integer and >> floating point types), and make them explicitly conform to >> ValuePreservingStringConvertible with an explicitly implemented >> “description” property. > > Yes to all of this, as others have already said. > >> >> - As a performance optimization, change the implementation of the >> string literal interpolation syntax to prefer the unlabeled >> initializer when interpolating a type that is >> ValuePreservingStringConvertible or that has otherwise has an >> unlabeled String initializer, but use the >> "String.init<T>(describing: T)” initializer if not. >> >> >> The expected advantages of this design are: >> >> - Swift encourages the T(x) syntax for value preserving conversions, and >> this design ensures that String(x) continues to work for the value >> preserving cases. > > Yes. I think doing a little more work to keep this convention is worthwhile. > >> >> - This ensures that the String(x) syntax does not accidentally fall >> off a performance cliff by using the extremely-dynamic reflection >> mechanism unintentionally. >> >> - The preferred “I don’t care how you do it, just convert this value >> to a string somehow” syntax remains string interpolation syntax. >> This syntax is efficient in the cases where the String(x) syntax is >> allowed, but fully general to the other cases where custom >> convert-to-string code has not been provided. >> >> >> 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. > > Any of the NSObject subclass candidates may require their > `description`s to be altered to meet the semantics, which may or may > not be an acceptable breaking change. > >> >> - 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? Yes. It would also be worth requiring that round-trip conversion works and produces an equivalent value. > 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. > > Today, `description` is definitely used for both lossless and lossy > string representations, and that's probably not going to change in the > future. > >> >> Thank you to Austin Zheng for driving this proposal forward! >> >> -Chris Lattner >> Review Manager >> >> >> _______________________________________________ >> swift-evolution-announce mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution-announce > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
