[swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Dmitri Gribenko]

On Sat, May 14, 2016 at 7:45 AM, Daniel Steinberg via swift-evolution
<swift-evolution at swift.org> wrote:
> I appreciate your rework on this - I still don’t understand one thing and
> disagree with a second:
>
> (1) I don’t understand what the word “Custom” adds to
> CustomStringRepresentable and CustomDebugStringRepresentable and would drop
> that prefix (even if it remains Convertible).

In Swift, every value has a string and a debugging string
representation, synthesized by the runtime.  These protocols allow
customizing the default behavior.  We don't want users to write any
APIs against these protocols, because it is the wrong thing to do.

In Swift 1, when the protocols were named Printable and
DebugPrintable, many users wrote APIs like this:

func printAll(_ values: [Printable]) {
  for x in values { print(x) }
}

'Printable' is a wrong constraint.  Everything is printable, and
user-defined types that are happy with the default string
representation don't customize it; structural types (function types,
tuples) can not adopt a protocol at all.  Users can't pass instances
of such types to this overconstrained API.  The right API to design
is:

func printAll(_ values: [Any]) {
  for x in values { print(x) }
}

Motivation behind renaming Printable to CustomStringRepresentable was
to discourage writing APIs against these protocols.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/