> On May 27, 2016, at 7:50 PM, Patrick Smith via swift-evolution > <[email protected]> wrote: > > Is there any possibility we can break from this? Especially as: > > 1. ValuePreservingStringConvertible expects its description to be value > preserving, but current Cocoa implementations are not. > 2. ‘Description’ doesn’t really convey the meaning of ‘value preserving’ in > my mind, but is a valuable name for many other use cases. > 3. Swift 3 has a wide range of breaking changes for the better. > 4. With the presence of ValuePreservingStringConvertible, > CustomStringConvertible doesn’t seem to provide much value over > CustomDebugStringConvertible? > > For string interpolation, I imagine the standard library could fall back to a > ‘description’ method for NSObject subclasses.
Personally, independent of the Cocoa precedent, I think that keeping “description” as the requirement of ValuePreservingStringConvertible is the right thing to do. Here is the proposed schema (ignoring the related but different “debug description”): 1) Values can always be converted to a string in Swift through reflection. 2) If a value wants a better, or more customized, string form, then it conforms to CustomStringConvertible. 3) If that string form is value preserving, it conforms to ValuePreservingStringConvertible, which is a refinement of CustomStringConvertible. In other words, this approach is saying that a value may be convertible to string in exactly one way. If that way is value preserving (i.e., can be reversed as DaveA suggests) then it can do so by conforming to the more specific protocol. The advantage of doing this is that it is now eligible for the String(x) syntax. This seems clean and simple. The only advantage to adding a new “stringRepresentation” requirement is if you wanted “description” to return one thing, but “stringRepresentation” to return another thing. There may be use cases for such a thing, but to me it just seems like new complexity added to the model for very little gain. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
