[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init<T>(_: T)

[Austin Zheng]

Thanks, I like "Lossless" too. Further suggestions on naming would be appreciated from anyone.

Austin

> On May 27, 2016, at 9:03 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >
> > on Thu May 26 2016, Patrick Smith <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/3c960e91/attachment.html>