> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md

I prefer the more conservative and backwards-compatible option of using 
`description` and conforming `ValuePreservingStringConvertible` to 
`CustomStringConvertible`. 

This is for three reasons:

* ValuePreservingStringConvertible really is a refinement of 
CustomStringConvertible's semantic; a value-preserving `description` should 
always be acceptable as an ordinary `description`.

* You should not call `description` directly anyway; you should call 
`String.init(_:)`. That makes the arguably non-descriptive name a lot less 
important.

* Changing the name of this property now will not actually make `description` 
available for the uses you want to put it to in most code. No amount of 
monkeying with the Swift standard library in 2016 can change the fact that the 
OpenStep specification took that name in 1994, and we need to interoperate with 
that heritage. You might free up the name `description` in value types and 
Linux-only code, but only at the cost of interoperability headaches. I don't 
think that's worth it.

I also think that, if we're serious about ValuePreservingStringConvertible's 
initializer restoring the full state of the instance, then it is a full-width 
conversion and doesn't need a label.

So, here's what I suggest:

        protocol CustomStringConvertible {
                var description: String { get }
        }
        protocol ValuePreservingStringConvertible: CustomStringConvertible {
                init?(_ description: String)
        }
        extension String {
                init<Value: ValuePreservingStringConvertible>(_ value: Value) { 
... }
                init<Value>(describing value: Value) { ... }
        }

Actually, I'd *like* to see `String.init(describing:)` constrained to 
CustomStringConvertible, but I've lost that argument before.

("Lossless" instead of "ValuePreserving" is fine too, perhaps even slightly 
better.)

-- 
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to