I don't recall whether it was in this thread or another that this point was made by the core team, but if I'm remembering correctly: it was shared that the protocol is now called CustomStringConvertible because conforming types provide a *custom* description, not merely an ordinary description.
If we follow that reasoning, ValuePreservingStringConvertible should *not* conform to CustomStringConvertible, because whether the description is value-preserving is orthogonal to whether it has been customized. But I share your concern that attempting to delete description from Swift will only increase interoperability headaches rather than freeing the name for other uses. On Sat, May 28, 2016 at 00:36 Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution