> - 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
