[swift-evolution] renaming CustomStringConvertible

Dmitri Gribenko gribozavr at gmail.com
Fri Jul 1 14:52:51 CDT 2016

On Fri, Jul 1, 2016 at 12:48 PM, Vladimir.S <svabox at gmail.com> wrote:
> 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.

They can still write this code, the compiler will accept it.  In
practice we found that changing the name helped and developers are now
much less likely to code APIs against CustomStringConvertible.  The
old name, Printable, strongly implied a capability (like Equatable,
Comparable, Hashable).  The new name does not suggest that
printability is a capability provided by this protocol.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list