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

Brent Royal-Gordon brent at architechies.com
Thu May 26 03:54:22 CDT 2016

> - Rename the existing reflection-based "String.init<T>(_: T)” initializer to "String.init<T>(describing: T)” as recommend by the community.  This initializer would rarely be invoked in user code directly.


> - Introduce a new protocol (for sake of discussion, call it “ValuePreservingStringConvertible") that refines CustomStringConvertible but that adds no new requirements.  Conformance to this protocol indicates that the “description” requirement produces a value-preserving representation in String form.


> - Introduce a new unlabeled initializer on String: "init<T: ValuePreservingStringConvertible>(_ v: T) { return v.description }".  This permits the “String(x)” syntax to be used on all values of types that can be converted to string in a value-preserving way.


> - Audit important standard library types (e.g. the integer and floating point types), and make them explicitly conform to ValuePreservingStringConvertible with an explicitly implemented “description” property.


> - As a performance optimization, change the implementation of the string literal interpolation syntax to prefer the unlabeled initializer when interpolating a type that is ValuePreservingStringConvertible or that has otherwise has an unlabeled String initializer, but use the "String.init<T>(describing: T)” initializer if not.

...huh. Well, if you insist.

(I would favor a design which somehow differentiated between strings intended for debugging or logging, which would permit any interpolation, and strings intended for paths, user display, and other such purposes, which would only permit ValuePreservingStringConvertible interpolations. But short of introducing a separate DebugString type, I'm not sure how we might actually accomplish that.)

Brent Royal-Gordon

More information about the swift-evolution mailing list