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

Brent Royal-Gordon brent at architechies.com
Mon May 30 01:23:34 CDT 2016


> Thanks Chris. I just meant where is that string going?
> 
> To a developer -> CustomDebugStringConvertible / Reflection
> To standard output -> Streamable
> To a user -> NSLocalizedString — no protocol (yet?)
> To an API / for serialisation -> LosslessStringConvertible
> To a playground -> CustomPlaygroundQuickLookable
> 
> CustomStringConvertible is left over, but doesn’t have a use case? Unless it’s an alternative to Streamable, but then why have Streamable?

There are *very* few conformances to Streamable in the standard library—just Character, String, and UnicodeScalar. I think that Streamable is for data that can be *directly* written to an output stream, whereas CustomStringConvertible is a way to convert an instance that *isn't* directly Streamable into something Streamable.

So, here's my version of your table:

User-readable, nonlocalized: CustomStringConvertible
User- and machine-readable, nonlocalized: LosslessStringConvertible
User-readable, localized: (nothing)
Developer-readable: CustomDebugStringConvertible

(Playground isn't necessarily working with strings, so it doesn't belong in this list.)

Localization is an obvious hole in our string conversions, but I think the reality here is that localization is part of a higher layer than the standard library. From what I can see, all of the "standard library" APIs which handle localization are actually part of Foundation. I'm sure that, if we build any localization-related features into the language, we'll add basic supporting code to the standard library if needed, but other than that, I don't think the standard library is the right place.

> I’m not sure if anyone else shares the concern, so I’ll leave it. I do believe it’s important however.

I do think this is an important concern, and I also think it's important to ask how interpolation interacts with it. For instance, I think it would be very useful to be able to say "interpolate developer representations" or "interpolate user representations" or "interpolate localized user representations", and have the compiler reject interpolated expressions which don't have the necessary representation.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list