# Proposal: conversion protocol naming conventions **URL:** \ **Category:** Discussion\ **Created:** [December 13, 2015, 2:40am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478 "2015-12-13T02:40:27Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 13, 2015, 2:40am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/1 "2015-12-13T02:40:27Z")
I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomStringProjectable` respectively I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). Thanks, Matthew ---
**Author:** ![Arthur](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/arthur/32/1375_2.png) [@Arthur](https://forums.swift.org/u/Arthur)\ **Post date:** [December 13, 2015, 3:28am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/2 "2015-12-13T03:28:08Z")
"The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomStringProjectable` respectively” I think the second CustomStringProjectable was meant to be CustomDebugStringProjectable. +1 to this change as it further builds upon the protocol naming conventions that were standardized in Swift 2.0. Best, Arthur / Sabintsev.com > **···** > > On December 12, 2015 at 9:40:32 PM, Matthew Johnson via swift-evolution (swift-evolution@swift.org) wrote: > > CustomStringProjectable ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 15, 2015, 4:28pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/3 "2015-12-15T16:28:53Z")
Bumping this thread. There wasn’t much response to the initial post, which may have been because Saturday night is probably not the best time to post a proposal. :) You can find the draft here: [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) The little feedback I did receive was positive. Matthew > **···** > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \ wrote: > > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomDebugStringProjectable` respectively > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > Thanks, > > Matthew > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Brad\_Hilton](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/brad_hilton/32/5169_2.png) [@Brad\_Hilton](https://forums.swift.org/u/Brad_Hilton)\ **Post date:** [March 3, 2016, 12:18am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/4 "2016-03-03T00:18:22Z")
Just going to put in my two cents: I think `Initializable` makes more sense than `Createable` or `Instantiable` assuming that we want to encourage protocols with initializers rather than static methods which aren’t as pretty. ;) I believe `Serializable` or `Representable` would be great for converting types to a given value. I’m also of the mind that `Convertible` should represent the combination of `Initializable` and `Serializable` protocols and may in many cases simply exist as a convenience protocol that inherits from the two. > **···** > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomStringProjectable` respectively > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > Thanks, > > Matthew ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 13, 2015, 3:29am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/5 "2015-12-13T03:29:56Z")
Yes Arthur, you are correct. That was a copy / paste error. The second should have been `CustomDebugStringProjectable`. I’m glad you like the proposal! > **···** > > > On Dec 12, 2015, at 9:28 PM, Arthur Sabintsev \ wrote: > > > > "The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomStringProjectable` respectively” > > > > I think the second CustomStringProjectable was meant to be CustomDebugStringProjectable. > > > > +1 to this change as it further builds upon the protocol naming conventions that were standardized in Swift 2.0. > > > > Best, > > > > Arthur / Sabintsev.com \<[http://sabintsev.com/>](http://sabintsev.com/>); > > On December 12, 2015 at 9:40:32 PM, Matthew Johnson via swift-evolution (swift-evolution@swift.org \) wrote: > > > > > CustomStringProjectable ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [December 15, 2015, 4:35pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/6 "2015-12-15T16:35:30Z")
There's something really promising here with respect to initialization and output. -- E > **···** > > > On Dec 15, 2015, at 9:28 AM, Matthew Johnson via swift-evolution \ wrote: > > > > Bumping this thread. There wasn’t much response to the initial post, which may have been because Saturday night is probably not the best time to post a proposal. :) > > > > You can find the draft here: [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > The little feedback I did receive was positive. > > > > Matthew > > > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \\> wrote: > > > > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomDebugStringProjectable` respectively > > > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > > > Thanks, > > > Matthew > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [December 15, 2015, 5:39pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/7 "2015-12-15T17:39:53Z")
And adding: I \*hate\* Convertible in its current form. Per your current write-up, the protocols should cover initialized from, converted to, and a mix. Let me suggest: \* can be initialized from: Instantiable, Initializable \* can be converted to: Expressible, Presentable, Projectable \* can be represented as and instantiated by: Convertible For example, IntegerLiteralInitializable, CustomStringRepresentationExpressible, and DoubleTypeConvertible. -- Erica > **···** > > > On Dec 15, 2015, at 9:28 AM, Matthew Johnson via swift-evolution \ wrote: > > > > Bumping this thread. There wasn’t much response to the initial post, which may have been because Saturday night is probably not the best time to post a proposal. :) > > > > You can find the draft here: [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > The little feedback I did receive was positive. > > > > Matthew > > > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \\> wrote: > > > > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomDebugStringProjectable` respectively > > > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > > > Thanks, > > > Matthew > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Andrew\_Brown](https://avatars.discourse-cdn.com/v4/letter/a/8e8cbc/32.png) [@Andrew\_Brown](https://forums.swift.org/u/Andrew_Brown)\ **Post date:** [December 15, 2015, 5:48pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/8 "2015-12-15T17:48:28Z")
+1 from me. Proposal is 'simple' and helps improve the overall clarity of the language. Perhaps add CustomStringProjectable and deprecate CustomStringConvertible in 2.2? ABR. > **···** > > > On 15 Dec 2015, at 16:28, Matthew Johnson via swift-evolution \ wrote: > > > > Bumping this thread. There wasn’t much response to the initial post, which may have been because Saturday night is probably not the best time to post a proposal. :) > > > > You can find the draft here: [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > The little feedback I did receive was positive. > > > > Matthew > > > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \ wrote: > > > > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomDebugStringProjectable` respectively > > > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > > > Thanks, > > > Matthew > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![hlovatt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hlovatt/32/3044_2.png) [@hlovatt](https://forums.swift.org/u/hlovatt)\ **Post date:** [March 3, 2016, 10:03pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/9 "2016-03-03T22:03:06Z")
I would prefer the name `Xxxable` to imply a method `xxx`. For example `CustomStringConvertable` becomes `Describable`, because its method is `description`. Similarly `IntergerLiteralConvertable` becomes `IntegerLiteralInitializable` because it has an `init` with a `integerLiteral` label. IE I am suggesting a one-to-one correspondence between the main 'method' name and the protocol name with 'able' added. > **···** > > On Thursday, 3 March 2016, Bradley Hilton via swift-evolution \< swift-evolution@swift.org \\> wrote: > > > Just going to put in my two cents: I think `Initializable` makes more > > sense than `Createable` or `Instantiable` assuming that we want to > > encourage protocols with initializers rather than static methods which > > aren’t as pretty. ;) I believe `Serializable` or `Representable` would be > > great for converting types to a given value. I’m also of the mind that > > `Convertible` should represent the combination of `Initializable` and > > `Serializable` protocols and may in many cases simply exist as a > > convenience protocol that inherits from the two. > > > > \> I have drafted a proposal to establish precise conventional meaning for > > the use of `Convertible`, `Representable`, and `Projectable` protocol > > suffixes. The proposal would require renaming `CustomStringConvertible` and > > `CustomDebugStringConvertible` to `CustomStringProjectable` and > > `CustomStringProjectable` respectively > > \> > > \> I am seeking input on the proposal before submitting a PR. The full > > draft can found at > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > \< > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > \>. > > \> > > \> Thanks, > > \> Matthew > > \> > > \> > > \> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > -- > -- Howard. ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 15, 2015, 5:47pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/10 "2015-12-15T17:47:51Z")
Thanks for your input Erica! I would be happy with any convention that establishes clarity and consistency. I wrote the proposal the way I did as it is the minimum change from current state that would establish clarity and consistency. My rationale was the smaller the change, the greater the chance of acceptance. It would be great to hear whether the community would prefer minimal change or wants to make a larger change if a better end result is possible that way. Matthew > **···** > > > On Dec 15, 2015, at 11:39 AM, Erica Sadun via swift-evolution \ wrote: > > > > And adding: > > > > I \*hate\* Convertible in its current form. Per your current write-up, the protocols should cover initialized from, converted to, and a mix. Let me suggest: > > > > \* can be initialized from: Instantiable, Initializable > > \* can be converted to: Expressible, Presentable, Projectable > > \* can be represented as and instantiated by: Convertible > > > > For example, IntegerLiteralInitializable, CustomStringRepresentationExpressible, and DoubleTypeConvertible. > > > > -- Erica > > > > > On Dec 15, 2015, at 9:28 AM, Matthew Johnson via swift-evolution \\> wrote: > > > > > > Bumping this thread. There wasn’t much response to the initial post, which may have been because Saturday night is probably not the best time to post a proposal. :) > > > > > > You can find the draft here: [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > > > The little feedback I did receive was positive. > > > > > > Matthew > > > > > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \\> wrote: > > > > > > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomDebugStringProjectable` respectively > > > > > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > > > > > Thanks, > > > > Matthew > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Brad\_Hilton](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/brad_hilton/32/5169_2.png) [@Brad\_Hilton](https://forums.swift.org/u/Brad_Hilton)\ **Post date:** [March 3, 2016, 10:23pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/11 "2016-03-03T22:23:16Z")
+1. This makes a lot of sense. > **···** > > On Thu, Mar 3, 2016 at 3:03 PM, Howard Lovatt \ wrote: > > > I would prefer the name `Xxxable` to imply a method `xxx`. For example > > `CustomStringConvertable` becomes `Describable`, because its method is > > `description`. Similarly `IntergerLiteralConvertable` becomes > > `IntegerLiteralInitializable` because it has an `init` with a > > `integerLiteral` label. IE I am suggesting a one-to-one correspondence > > between the main 'method' name and the protocol name with 'able' added. > > > > On Thursday, 3 March 2016, Bradley Hilton via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > > Just going to put in my two cents: I think `Initializable` makes more > > > sense than `Createable` or `Instantiable` assuming that we want to > > > encourage protocols with initializers rather than static methods which > > > aren’t as pretty. ;) I believe `Serializable` or `Representable` would be > > > great for converting types to a given value. I’m also of the mind that > > > `Convertible` should represent the combination of `Initializable` and > > > `Serializable` protocols and may in many cases simply exist as a > > > convenience protocol that inherits from the two. > > > > > > \> I have drafted a proposal to establish precise conventional meaning for > > > the use of `Convertible`, `Representable`, and `Projectable` protocol > > > suffixes. The proposal would require renaming `CustomStringConvertible` and > > > `CustomDebugStringConvertible` to `CustomStringProjectable` and > > > `CustomStringProjectable` respectively > > > \> > > > \> I am seeking input on the proposal before submitting a PR. The full > > > draft can found at > > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > \< > > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > \>. > > > \> > > > \> Thanks, > > > \> Matthew > > > \> > > > \> > > > \> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > -- > > -- Howard. ---
**Author:** ![dabrahams](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dabrahams/32/9815_2.png) [@dabrahams](https://forums.swift.org/u/dabrahams)\ **Post date:** [March 4, 2016, 1:42am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/12 "2016-03-04T01:42:01Z")
> I would prefer the name `Xxxable` to imply a method `xxx`. For example > `CustomStringConvertable` becomes `Describable`, because its method is > `description`. Similarly `IntergerLiteralConvertable` becomes > `IntegerLiteralInitializable` because it has an `init` with a > `integerLiteral` label. IE I am suggesting a one-to-one correspondence > between the main 'method' name and the protocol name with 'able' > added. I don't know about this; I don't think I want to be forced to rename Comparable or Equatable. > **···** > > on Thu Mar 03 2016, Howard Lovatt \ wrote: > > > On Thursday, 3 March 2016, Bradley Hilton via swift-evolution \< \> swift-evolution@swift.org \> \\> wrote: > > > > > Just going to put in my two cents: I think `Initializable` makes more > > > sense than `Createable` or `Instantiable` assuming that we want to > > > encourage protocols with initializers rather than static methods which > > > aren’t as pretty. ;) I believe `Serializable` or `Representable` would be > > > great for converting types to a given value. I’m also of the mind that > > > `Convertible` should represent the combination of `Initializable` and > > > `Serializable` protocols and may in many cases simply exist as a > > > convenience protocol that inherits from the two. > > > > > > \> I have drafted a proposal to establish precise conventional meaning for > > > the use of `Convertible`, `Representable`, and `Projectable` protocol > > > suffixes. The proposal would require renaming `CustomStringConvertible` and > > > `CustomDebugStringConvertible` to `CustomStringProjectable` and > > > `CustomStringProjectable` respectively > > > \> > > > \> I am seeking input on the proposal before submitting a PR. The full > > > draft can found at > > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > \< > > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > \>. > > > \> > > > \> Thanks, > > > \> Matthew > > > \> > > > \> > > > \> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > -- > -Dave ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [March 4, 2016, 2:18am UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/13 "2016-03-04T02:18:45Z")
Adding onto what Dave said: Although the notion of tying a protocol name to a specific method or function is superficially appealing, it fails in my opinion for the following reasons: \* Protocols may not include any methods or function. A protocol may consist of one or more properties, subscripts, or associated types. \* Many protocols include multiple methods and functions. Which is the magic one that controls the naming? \* Protocols describe their purpose or their artifact. There may be no direct semantic connection from that purpose or artifact to a specific method or function name. \* The words Matthew and I propose are modifiers. The key semantics are found in the other half of the protocol name. "This item can be created from \", "This item can be converted to and from \" and "This item can be represented as \". Best regards, -- E > **···** > > > On Mar 3, 2016, at 6:42 PM, Dave Abrahams via swift-evolution \ wrote: > > > > on Thu Mar 03 2016, Howard Lovatt \ wrote: > > > > > I would prefer the name `Xxxable` to imply a method `xxx`. For example > > > `CustomStringConvertable` becomes `Describable`, because its method is > > > `description`. Similarly `IntergerLiteralConvertable` becomes > > > `IntegerLiteralInitializable` because it has an `init` with a > > > `integerLiteral` label. IE I am suggesting a one-to-one correspondence > > > between the main 'method' name and the protocol name with 'able' > > > added. > > > > I don't know about this; I don't think I want to be forced to rename > > Comparable or Equatable. > > > > > On Thursday, 3 March 2016, Bradley Hilton via swift-evolution \< \>\> swift-evolution@swift.org \>\> \\> wrote: > > > > > > > Just going to put in my two cents: I think `Initializable` makes more > > > > sense than `Createable` or `Instantiable` assuming that we want to > > > > encourage protocols with initializers rather than static methods which > > > > aren’t as pretty. ;) I believe `Serializable` or `Representable` would be > > > > great for converting types to a given value. I’m also of the mind that > > > > `Convertible` should represent the combination of `Initializable` and > > > > `Serializable` protocols and may in many cases simply exist as a > > > > convenience protocol that inherits from the two. > > > > > > > > > I have drafted a proposal to establish precise conventional meaning for > > > > > > > > the use of `Convertible`, `Representable`, and `Projectable` protocol > > > > suffixes. The proposal would require renaming `CustomStringConvertible` and > > > > `CustomDebugStringConvertible` to `CustomStringProjectable` and > > > > `CustomStringProjectable` respectively > > > > > > > > > I am seeking input on the proposal before submitting a PR. The full > > > > > > > > draft can found at > > > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > \< > > > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > > > > > > . > > > > > > > > > > Thanks, > > > > > Matthew > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > -- > > -Dave > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [December 15, 2015, 5:59pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/14 "2015-12-15T17:59:02Z")
The great advantage of basic renaming is that migration is super-simple. And now that I think about it, CustomStringRepresentable is probably a lot better than CustomStringRepresentationExpressible It's easy enough to take some time, throw some options out there, and come up with names that better represent the concepts in question (the big win of your proposal) and then vote for the best. -- E p.s. Does anyone ever actually use debugString stuff? I love it in concept but I find that I use it about 0% of the time > **···** > > > On Dec 15, 2015, at 10:47 AM, Matthew Johnson \ wrote: > > > > Thanks for your input Erica! I would be happy with any convention that establishes clarity and consistency. > > > > I wrote the proposal the way I did as it is the minimum change from current state that would establish clarity and consistency. My rationale was the smaller the change, the greater the chance of acceptance. > > > > It would be great to hear whether the community would prefer minimal change or wants to make a larger change if a better end result is possible that way. > > > > Matthew > > > > > On Dec 15, 2015, at 11:39 AM, Erica Sadun via swift-evolution \\> wrote: > > > > > > And adding: > > > > > > I \*hate\* Convertible in its current form. Per your current write-up, the protocols should cover initialized from, converted to, and a mix. Let me suggest: > > > > > > \* can be initialized from: Instantiable, Initializable > > > \* can be converted to: Expressible, Presentable, Projectable > > > \* can be represented as and instantiated by: Convertible > > > > > > For example, IntegerLiteralInitializable, CustomStringRepresentationExpressible, and DoubleTypeConvertible. > > > > > > -- Erica > > > > > > > On Dec 15, 2015, at 9:28 AM, Matthew Johnson via swift-evolution \\> wrote: > > > > > > > > Bumping this thread. There wasn’t much response to the initial post, which may have been because Saturday night is probably not the best time to post a proposal. :) > > > > > > > > You can find the draft here: [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > > > > > The little feedback I did receive was positive. > > > > > > > > Matthew > > > > > > > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \\> wrote: > > > > > > > > > > I have drafted a proposal to establish precise conventional meaning for the use of `Convertible`, `Representable`, and `Projectable` protocol suffixes. The proposal would require renaming `CustomStringConvertible` and `CustomDebugStringConvertible` to `CustomStringProjectable` and `CustomDebugStringProjectable` respectively > > > > > > > > > > I am seeking input on the proposal before submitting a PR. The full draft can found at [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md\](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md%5C). > > > > > > > > > > Thanks, > > > > > Matthew > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org \ > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 15, 2015, 6:09pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/15 "2015-12-15T18:09:55Z")
> It's easy enough to take some time, throw some options out there, and come up with names that better represent the concepts in question (the big win of your proposal) and then vote for the best. Sure, that sounds like a great idea to me as long as the core team is willing to consider a larger scale change to existing names (primarily all the \*LiteralConvertible protocols). ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 15, 2015, 6:15pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/16 "2015-12-15T18:15:45Z")
> The great advantage of basic renaming is that migration is super-simple. Renaming is simple but communicating and re-educating everyone using Swift is somewhat less so. I don't mind it but imagine some would and some will argue against a larger change on that basis. Personally, I would like it if we go with the best names we can come up with so I do nudge in this direction. > And now that I think about it, CustomStringRepresentable is probably a lot better than CustomStringRepresentationExpressible Representable is what I would have used if I wasn't trying to make a minimal change or if RawRepresentable didn't already use it for bidirectional conversion, so I agree that it is better than both Expressible and Projectable. Matthew ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 15, 2015, 6:18pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/17 "2015-12-15T18:18:19Z")
> \* can be initialized from: Instantiable, Initializable It probably makes sense to consider protocols that use factory methods rather than initializers for the "from" case. Instantiable seems a bit clunky but does make more sense in the context of factory methods. ---
**Author:** ![ilya](https://avatars.discourse-cdn.com/v4/letter/i/58f4c7/32.png) [@ilya](https://forums.swift.org/u/ilya)\ **Post date:** [December 15, 2015, 6:01pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/18 "2015-12-15T18:01:40Z")
> p.s. Does anyone ever actually use debugString stuff? I love it in concept but I find that I use it about 0% of the time Composite types (array, optional, ...) display debugString output > **···** > > On Tue, Dec 15, 2015 at 20:59 Erica Sadun via swift-evolution \< swift-evolution@swift.org\> wrote: > > > The great advantage of basic renaming is that migration is super-simple. > > And now that I think about it, CustomStringRepresentable is probably a > > lot better than CustomStringRepresentationExpressible > > > > It's easy enough to take some time, throw some options out there, and come > > up with names that better represent the concepts in question (the big win > > of your proposal) and then vote for the best. > > > > -- E > > p.s. Does anyone ever actually use debugString stuff? I love it in concept > > but I find that I use it about 0% of the time > > > > On Dec 15, 2015, at 10:47 AM, Matthew Johnson \ \> wrote: > > > > Thanks for your input Erica! I would be happy with any convention that > > establishes clarity and consistency. > > > > I wrote the proposal the way I did as it is the minimum change from > > current state that would establish clarity and consistency. My rationale > > was the smaller the change, the greater the chance of acceptance. > > > > It would be great to hear whether the community would prefer minimal > > change or wants to make a larger change if a better end result is possible > > that way. > > > > Matthew > > > > On Dec 15, 2015, at 11:39 AM, Erica Sadun via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > And adding: > > > > I \*hate\* Convertible in its current form. Per your current write-up, the > > protocols should cover initialized from, converted to, and a mix. Let me > > suggest: > > > > \* can be initialized from: Instantiable, Initializable > > \* can be converted to: Expressible, Presentable, Projectable > > \* can be represented as and instantiated by: Convertible > > > > For example, IntegerLiteralInitializable, > > CustomStringRepresentationExpressible, and DoubleTypeConvertible. > > > > -- Erica > > > > On Dec 15, 2015, at 9:28 AM, Matthew Johnson via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > Bumping this thread. There wasn’t much response to the initial post, > > which may have been because Saturday night is probably not the best time to > > post a proposal. :) > > > > You can find the draft here: > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > > > The little feedback I did receive was positive. > > > > Matthew > > > > On Dec 12, 2015, at 8:40 PM, Matthew Johnson via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > I have drafted a proposal to establish precise conventional meaning for > > the use of `Convertible`, `Representable`, and `Projectable` protocol > > suffixes. The proposal would require renaming `CustomStringConvertible` > > and `CustomDebugStringConvertible` to `CustomStringProjectable` > > and `CustomDebugStringProjectable` respectively > > > > I am seeking input on the proposal before submitting a PR. The full draft > > can found at > > [https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md](https://github.com/anandabits/swift-evolution/blob/conversion-protocol-conventions/proposals/0000-conversion-protocol-conventions.md) > > . > > > > Thanks, > > Matthew > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [December 15, 2015, 6:39pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/19 "2015-12-15T18:39:43Z")
There is ample precedent however. If memory serves: the printable protocol, the playground quicklook one, etc -- E > **···** > > > On Dec 15, 2015, at 11:15 AM, Matthew Johnson \ wrote: > > > > > The great advantage of basic renaming is that migration is super-simple. > > > > Renaming is simple but communicating and re-educating everyone using Swift is somewhat less so. I don't mind it but imagine some would and some will argue against a larger change on that basis. Personally, I would like it if we go with the best names we can come up with so I do nudge in this direction. ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [December 15, 2015, 10:32pm UTC](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478/20 "2015-12-15T22:32:48Z")
Let's run with the idea that everything is up for grabs and that better names will better serve the developer community in the long run. In such a case, if the core naming patterns were established as Convertible for bidirectional conversion, would RawConvertible be such a bad thing? -- Erica > **···** > > > On Dec 15, 2015, at 11:15 AM, Matthew Johnson \ wrote: > > > > > And now that I think about it, CustomStringRepresentable is probably a lot better than CustomStringRepresentationExpressible > > > > Representable is what I would have used if I wasn't trying to make a minimal change or if RawRepresentable didn't already use it for bidirectional conversion, so I agree that it is better than both Expressible and Projectable. > > > > Matthew [Next page](https://forums.swift.org/t/proposal-conversion-protocol-naming-conventions/478.md?page=2)