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

[David Hart]

> - If its conformers produce a value-preserving representation, would it make sense for it to also have an initializer accepting the value? What specifically makes it value preserving otherwise?

This makes sense to me. But we are getting dangerously close to a Serialization feature which could benefit a more complex and generic design.

> - What is the difference between CustomStringConvertible and CustomDebugStringConvertible? Are most implementations of description and debugDescription identical? It says CustomStringConvertible is for writing to an output stream. Is a ‘value preserving string’ going to be a better fit for that all the time?

I’ve always found those two confusing. But I guess that CustomDebugStringConvertible could provide more information, like the actual type and pointer value. For example, imagine that we make UIColor ValuePreservingStringConvertible, one implementation could look like:

let a = UIColor(red: 0, green: 0, blue: 0)
a.description // #000000
a.debugDescription // <UIColor: 0xcodebeef - red: 0.0, green: 0.0, blue: 0.0>

> - To the question of ‘is CustomStringConvertible enough?’, what about replacing it with ValuePreservingStringConvertible? Then there are two very distinct protocols: ValuePreservingStringConvertible and CustomDebugStringConvertible, one obviously safely value preserving and one obviously just for inspecting.
> 
> - Could `.description` be renamed to something more specific and clear? For example, `preservedValue` or `.valuePreservingDescription`. If the recommended way is to use `init<T: ValuePreservingStringConvertible>(_ v: T)`, will anybody be using `.description` directly anyway? I always found NSObject’s seize of the ‘description’ property annoying, as on models it’s a perfect valid property to want as a member, so I was a little disappointed to see it in Swift too. If there’s an alternative, more clear name for this property then it won’t clash with anything else.
> 
> I like this clear separation of ‘value preserving’ and ‘just show me something’ representations.
> 
> Patrick
> 
> 
>> On 26 May 2016, at 3:08 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>> 
>> The review of "SE-0089: Renaming String.init<T>(_: T)" ran from May 17…23, 2016. The proposal has been *returned for revision* and another round of discussion - the core team would love to see the revised proposal make it into Swift 3.
>> 
>> The community and core team both want to remove this “footgun” from the standard library, where someone could write "String(x)” with the intention of getting a value-preserving conversion to String, but may instead get a potentially lossy and potentially expensive reflection-based conversion to a String.  After extensive discussion, the core team recommends that the community consider a somewhat more elaborate design:
>> 
>> - Rename the existing reflection-based "String.init<T>(_: T)” initializer to "String.init<T>(describing: T)” as recommend by the community.  This initializer would rarely be invoked in user code directly.
>> 
>> - Introduce a new protocol (for sake of discussion, call it “ValuePreservingStringConvertible") that refines CustomStringConvertible but that adds no new requirements.  Conformance to this protocol indicates that the “description” requirement produces a value-preserving representation in String form.
>> 
>> - Introduce a new unlabeled initializer on String: "init<T: ValuePreservingStringConvertible>(_ v: T) { return v.description }".  This permits the “String(x)” syntax to be used on all values of types that can be converted to string in a value-preserving way.
>> 
>> - Audit important standard library types (e.g. the integer and floating point types), and make them explicitly conform to ValuePreservingStringConvertible with an explicitly implemented “description” property.
>> 
>> - As a performance optimization, change the implementation of the string literal interpolation syntax to prefer the unlabeled initializer when interpolating a type that is ValuePreservingStringConvertible or that has otherwise has an unlabeled String initializer, but use the "String.init<T>(describing: T)” initializer if not.
>> 
>> 
>> The expected advantages of this design are:
>> 
>> - Swift encourages the T(x) syntax for value preserving conversions, and this design ensures that String(x) continues to work for the value preserving cases.
>> 
>> - This ensures that the String(x) syntax does not accidentally fall off a performance cliff by using the extremely-dynamic reflection mechanism unintentionally.
>> 
>> - The preferred “I don’t care how you do it, just convert this value to a string somehow” syntax remains string interpolation syntax.  This syntax is efficient in the cases where the String(x) syntax is allowed, but fully general to the other cases where custom convert-to-string code has not been provided.
>> 
>> 
>> Some remaining open questions:
>> 
>> - Exactly what types should conform to ValuePreservingStringConvertible.  It seems clear that integer, floating point types, and Character can and should conform.  What other types should?
>> 
>> - Do we need the ValuePreservingStringConvertible at all, or is the existing CustomStringConvertible enough?  We already have a few protocols for handling string convertibility, it would be great to avoid adding another one.
>> 
>> Thank you to Austin Zheng for driving this proposal forward!
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution