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

[Patrick Smith]

Thank you Brent. I like your points, and agree that localisation is not a simple problem. Also interesting to see the latest discussion (from Vladimir, Dave, Austin, and Hooman).

Replied inline below:

> On 30 May 2016, at 4:23 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> 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.

OK, that’s an interesting distinction (and interesting protocol in Streamable — it feels as though it has some functionality to come).

For developers, like ourselves, it seems straight-forward that a string is this simple primitive. We get them in, we process them, and we spit them back out. However, this is a flawed system, as it one that is made easiest for the programmer, and is really designed for a context where the user is also a programmer. It best suits technical scenarios such as configuration files, environment variables, and command line arguments, as Brent suggests. However, I don’t think this is the best case to design for.

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

The first item in your table ‘User-readable, non-localised’, is the big problem area to me. Ideally in my mind all of these should be moved to other areas, such as the second area that LosslessStringConvertible occupies, which command line arguments and configuration keys certainly could. And user-readable should use a system that always allows localisation to be added progressively, by use of type extensions or protocols.

In a UI application, everything that is displayed should be using a system which allows localisation. I would argue a command line tool is also a UI application. I would not advocate for a full-on locale system like the one Foundation has to be brought to the Swift standard library (unless eventually it’s easy to integrate a standard a la Unicode).

> 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 believe best practices can be put in place with a system no more complicated for the programmer than the one we have now. This could be possible with protocols: a core protocols in the standard library that are then fleshed out in a Foundation-level framework above, with Locale / CultureCode / etc types extending or conforming.

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

I like this idea. I think “interpolate localised user representations” should not be distinct from “interpolate user representations”. Instead non-localised is specifically denoted as ‘technical’ or perhaps ‘en-US’. Locales, or more broadly ‘contexts’, are not something additional, instead, everything already has a context, and the context of a string could be made more explicit.

> 
> -- 
> Brent Royal-Gordon
> Architechies
>