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

[Brent Royal-Gordon]

> - 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.

Yes.

> - 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.

Yes!

> - 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.

YES!

> - 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.

HELL YES!

> - 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
Architechies