[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init<T>(_: T)
pgwsmith at gmail.com
Sun May 29 23:39:13 CDT 2016
Thanks Chris. I just meant where is that string going?
To a developer -> CustomDebugStringConvertible / Reflection
To standard output -> Streamable
To a user -> NSLocalizedString — no protocol (yet?)
To an API / for serialisation -> LosslessStringConvertible
To a playground -> CustomPlaygroundQuickLookable
CustomStringConvertible is left over, but doesn’t have a use case? Unless it’s an alternative to Streamable, but then why have Streamable? People will use ‘description’ for multiple use cases, which makes sense when you are both a developer and a user, or your users are developers like with a command-line tool, so there doesn’t seem to be any grey. But I believe there is, and that it is beneficial to pin it to one of the use cases above, and to have dedicated clear-cut protocols for each use case.
I’m not sure if anyone else shares the concern, so I’ll leave it. I do believe it’s important however.
> On 30 May 2016, at 5:16 AM, Chris Lattner <clattner at apple.com> wrote:
>> On May 28, 2016, at 10:46 PM, Patrick Smith <pgwsmith at gmail.com> wrote:
>> Thanks for replying Chris!
>>> On 29 May 2016, at 6:00 AM, Chris Lattner <clattner at apple.com> wrote:
>>> 2) If a value wants a better, or more customized, string form, then it conforms to CustomStringConvertible.
>> What are the use cases for this more customized string form?
> print() and string interpolation use it. You conform to it and implement it when you want something specific to your type, otherwise you get the default reflection based implementation. The reflection implementation is better than nothing, but usually not what you want.
More information about the swift-evolution