This looks good. I like your use of the term "lossless"; perhaps we can use it consistently, i.e. LosslessStringConvertible. The implication by comparison would be that CustomStringConvertible makes no guarantee of losslessness. On Fri, May 27, 2016 at 23:52 Austin Zheng via swift-evolution < [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 > > 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]> 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]> 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 >> > > _______________________________________________ > 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
