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

[Vladimir.S]

 > 1) Values can always be converted to a string in Swift through reflection.
 > 2) If a value wants a better, or more customized, string form, then it 
conforms to CustomStringConvertible.
 > 3) If that string form is value preserving, it conforms to 
ValuePreservingStringConvertible, which is a refinement of 
CustomStringConvertible.

I can't understand this. For me ValuePreservingStringConvertible usually 
will be different than CustomStringConvertible. Can't I want to have some 
string view of my struct to present data(also in UI) *and* value preserving 
string value for the same struct?
So my .description will show something like "12.345-6.78" and value 
preserving string will contain something like 
"19083749347923847293487293483" to encode the data of the struct. No?

Btw, also I can't understand how we can use `description` property name to 
contain 'value preserving' string. IMO 'description' in this case does not 
reflect the meaning of contained data.

On 28.05.2016 23:00, Chris Lattner via swift-evolution wrote:
>
>> On May 27, 2016, at 7:50 PM, Patrick Smith via swift-evolution <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.
>
> Personally, independent of the Cocoa precedent, I think that keeping “description” as the requirement of ValuePreservingStringConvertible is the right thing to do.
>
> Here is the proposed schema (ignoring the related but different “debug description”):
>
> 1) Values can always be converted to a string in Swift through reflection.
> 2) If a value wants a better, or more customized, string form, then it conforms to CustomStringConvertible.
> 3) If that string form is value preserving, it conforms to ValuePreservingStringConvertible, which is a refinement of CustomStringConvertible.
>
> In other words, this approach is saying that a value may be convertible to string in exactly one way.  If that way is value preserving (i.e., can be reversed as DaveA suggests) then it can do so by conforming to the more specific protocol.  The advantage of doing this is that it is now eligible for the String(x) syntax.
>
> This seems clean and simple.  The only advantage to adding a new “stringRepresentation” requirement is if you wanted “description” to return one thing, but “stringRepresentation” to return another thing.  There may be use cases for such a thing, but to me it just seems like new complexity added to the model for very little gain.
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>