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. Patrick > On 30 May 2016, at 5:16 AM, Chris Lattner <[email protected]> wrote: > > >> On May 28, 2016, at 10:46 PM, Patrick Smith <[email protected]> wrote: >> >> Thanks for replying Chris! >> >>> On 29 May 2016, at 6:00 AM, Chris Lattner <[email protected]> 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. > > -Chris > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
