<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Some feedback:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Lossless sounds nice to me. Or ‘canonical’ I had wondered, but lossless sounds better.</div><div class=""><br class=""></div><div class=""><div class=""><i class="">• 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, <b class="">stringRepresentation will simply return description</b>.</i></div></div><div class="">---</div><div class="">I think this should instead say <b class="">description will simply return stringRepresentation</b>, as it is more of a source of truth, and description is derivative</div><div class=""><br class=""></div><div class=""><i class="">• CustomStringConvertible will provide a human-readable description of an instance. It may provide as little or as much detail as deemed appropriate.</i></div><div class=""><div class=""><i class="">• 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></div></div><div class=""><div class="">---</div><div class="">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.</div><div class=""></div></div><div class=""><br class=""></div><div class="">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: <a href="https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L319" class="">https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L319</a></div><div class=""><br class=""></div><div class="">Not having ‘description’ taken means we can create a struct like so without clashing:</div><div class=""><br class=""></div><div class="">struct Channel {</div><div class=""> let title: String</div><div class=""> let link: NSURL</div><div class=""> let description: String</div><div class="">}</div><div class=""><br class=""></div><div class="">Patrick</div><div class=""> </div><br class=""><div><blockquote type="cite" class=""><div class="">On 28 May 2016, at 1:51 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello swift-evolution,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md" class="">https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md</a><br class=""></div><div class=""><br class=""></div><div class="">If any objections can be worked out quickly, I hope to resubmit this proposal for review early next week.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 27, 2016 at 7:50 PM, Patrick Smith via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there any possibility we can break from this? Especially as:<br class="">
<br class="">
1. ValuePreservingStringConvertible expects its description to be value preserving, but current Cocoa implementations are not.<br class="">
2. ‘Description’ doesn’t really convey the meaning of ‘value preserving’ in my mind, but is a valuable name for many other use cases.<br class="">
3. Swift 3 has a wide range of breaking changes for the better.<br class="">
4. With the presence of ValuePreservingStringConvertible, CustomStringConvertible doesn’t seem to provide much value over CustomDebugStringConvertible?<br class="">
<br class="">
For string interpolation, I imagine the standard library could fall back to a ‘description’ method for NSObject subclasses.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Patrick<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
> On 28 May 2016, at 7:49 AM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
><br class="">
> on Thu May 26 2016, Patrick Smith <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
>>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>>><br class="">
>>> Any of the NSObject subclass candidates may require their<br class="">
>>> `description`s to be altered to meet the semantics, which may or may<br class="">
>>> not be an acceptable breaking change.<br class="">
>><br class="">
>> Do you think it might be worth changing `description` to be named<br class="">
>> something else? Something more clear, less likely to conflict with<br class="">
>> ‘real’ properties — ‘description’ doesn’t seem to portray something<br class="">
>> that is value-preserving. What is the reason for calling it<br class="">
>> ‘description’?<br class="">
><br class="">
> The main reason was backward compatibility with Cocoa, which already has<br class="">
> a “description” property.<br class="">
><br class="">
>> Especially if NSObject subclasses won’t fit, then why not have a<br class="">
>> different method that can be strictly value preserving? (Then<br class="">
>> `description` can stay being an NSObject thing.)<br class="">
><br class="">
> --<br class="">
> Dave<br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>