I like the design strategy, but I’m having a hard time seeing the value of `ValuePreservingStringConvertible`; it’d be easier to evaluate the need for it with some concrete examples of types with `description` implementations that:
- aren’t value-preserving - would cause problems if mistakenly-classified as value-preserving Relatedly, here are some concrete `description`/`debugDescription` pairs; would these `description`s be value-preserving or not? - a `Wavelength` type - description: “650.0 nm” - debugDescription: “Wavelength(nanometers: 650.0)” - an `Angle` type: - description: “90.0°” - debugDescription: “Angle(πUnits: 0.5)” …(note that neither type has a corresponding `init?(_ string: String)` implementation, and I don’t plan to add one either). I’m just having trouble coming up with realistic non-value-preserving descriptions that’d be *problematic* (as opposed to just, say, unhelpful). > On May 26, 2016, at 12:08 AM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> 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. > > - 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. > > - 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? > > - 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. > > Thank you to Austin Zheng for driving this proposal forward! > > -Chris Lattner > Review Manager > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
