[swift-evolution] renaming CustomStringConvertible

[Vladimir.S]

On 01.07.2016 22:22, Dmitri Gribenko via swift-evolution wrote:
> On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> To the Swift community,
>>
>> May I put forth a couple of new names for the following protocol:
>>
>>
>> - CustomStringConvertible  —   rename as ‘Descriptive’ or as ‘Revealable’
>>
>>
>> Two goals for Swift is clarity and joy in use of the language, so I strongly
>> feel that ‘Custom-‘ not be part of any new name here since it contributes
>> little except verbosity
>
> Hi Eric,
>
> This protocol was called Printable before, but it caused a lot of
> confusion for developers, and was guiding the developers toward
> writing incorrect APIs.  We have seen a lot of developers writing code
> like this:
>
> func printAll(_ values: [Printable]) {
>   for v in values { print(v) }
> }
>
> This code is unnecessarily restrictive since in Swift everything can
> be converted into a String.

Yes, but IMO someone, who don't know this can still write

func printAll(_ values: [CustomStringConvertible]) {
   for v in values { print(v) }
}

So, I don't see how this name should help to understand that "everything 
can be converted into a String". This is a knowledge that one should read 
in docs, IMO.

For me it seems logical: "everything could be printed" + "but those who is 
Descriptive, will be printed by their .description property".

As for CustomStringConvertible, it seems like you need .asCustromString (or 
just .asString) property, not .description. This confuses. Or each "thing" 
should have .description/.asString, but one who needs can override it(to be 
"custom" representable).

Just some thoughts.

>
> func printAll(_ values: [Any]) {
>   for v in values { print(v) }
> }
>
> The same goes for retrieving debug descriptions and mirrors.  Any
> value can do that.  It is just that some values can opt into
> customizing this behavior.
>
> Thus, we renamed the protocols, adding the Custom~ prefix.  Our
> intention was to encourage only conformances to these protocols, and
> discourage writing APIs against them.
>
> Dmitri
>