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

Brent Royal-Gordon brent at architechies.com
Fri May 27 23:36:20 CDT 2016

> 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

More information about the swift-evolution mailing list