Some feedback: I wonder if ValuePreservingStringConvertible having an initializer restricts its use case at all? Plus, ValuePreservingStringConvertible seems very similar to RawRepresentable with a RawValue of String.
Lossless sounds nice to me. Or ‘canonical’ I had wondered, but lossless sounds better. • The standard library will be audited. Any type which can be reasonably represented as a string in a value-preserving way will be modified to conform to ValuePreservingStringConvertible. If they conform to CustomStringConvertible and their existing description is value-preserving, stringRepresentation will simply return description. --- I think this should instead say description will simply return stringRepresentation, as it is more of a source of truth, and description is derivative • CustomStringConvertible will provide a human-readable description of an instance. It may provide as little or as much detail as deemed appropriate. • CustomDebugStringConvertible will provide a human-readable description of an instance. It can provide additional information relative to CustomStringConvertible, information that would not be pertinent for consumers of descriptions (such as human readers or other APIs), but would be useful for development or diagnostic purposes. --- I think this reasoning for having both CustomStringConvertible and CustomDebugStringConvertible doesn’t really hold up. It’s a little bit vague. If it’s for an API, then the lossless value is the better choice. If it’s for people, then either a localised value (which description is not) or the lossless string representation is a better choice. I know I keep repeating this, but I can’t see any use cases for a ‘description’ property. I think ‘stringRepresentation’ and ‘debugDescription’ cover all use cases. The ‘description’ property is never accessed by developers, instead as the Swift team’s feedback said `String.init<T>(describing: T)` or `"\(interpolation)"` is to be used, and I think they can detect and fallback to `NSObject.description’ for Objective-C objects, e.g. in _print_unlocked() here: https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L319 Not having ‘description’ taken means we can create a struct like so without clashing: struct Channel { let title: String let link: NSURL let description: String } Patrick > On 28 May 2016, at 1:51 PM, Austin Zheng <[email protected]> wrote: > > Hello swift-evolution, > > I've put together a preliminary v2 of the proposal, taking into account > feedback expressed on this thread. I would appreciate any comments, > suggestions, or criticisms. > > https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md > > <https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md> > > If any objections can be worked out quickly, I hope to resubmit this proposal > for review early next week. > > Best, > Austin > > > On Fri, May 27, 2016 at 7:50 PM, Patrick Smith via swift-evolution > <[email protected] <mailto:[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. > > Thanks, > > Patrick > > > On 28 May 2016, at 7:49 AM, Dave Abrahams via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > on Thu May 26 2016, Patrick Smith <[email protected] > > <mailto:[email protected]>> wrote: > > > >>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution > >>> <[email protected] <mailto:[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] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
