> 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
<[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
