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. Thanks, Patrick > On 28 May 2016, at 7:49 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Thu May 26 2016, Patrick Smith <[email protected]> wrote: > >>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution >>> <[email protected]> wrote: >>> >>> 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 you think it might be worth changing `description` to be named >> something else? Something more clear, less likely to conflict with >> ‘real’ properties — ‘description’ doesn’t seem to portray something >> that is value-preserving. What is the reason for calling it >> ‘description’? > > The main reason was backward compatibility with Cocoa, which already has > a “description” property. > >> Especially if NSObject subclasses won’t fit, then why not have a >> different method that can be strictly value preserving? (Then >> `description` can stay being an NSObject thing.) > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
