Proposal: conversion protocol naming conventions


(Matthew Johnson) #1

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.

Thanks,
Matthew


(Arthur Ariel Sabintsev) #2

"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


(Matthew Johnson) #3

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

You can find the draft here: 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.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brad Hilton) #4

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

Thanks,
Matthew


(Matthew Johnson) #5

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 <arthur@sabintsev.com> 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/>
On December 12, 2015 at 9:40:32 PM, Matthew Johnson via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:

CustomStringProjectable


(Erica Sadun) #6

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

You can find the draft here: 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 <mailto: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.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #7

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

You can find the draft here: 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 <mailto: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.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Andrew Brown) #8

+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 <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. :slight_smile:

You can find the draft here: 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.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #9

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 <javascript:_e(%7B%7D,'cvml','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. :wink: 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
>.
>
> Thanks,
> Matthew
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


(Matthew Johnson) #10

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 <mailto: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. :slight_smile:

You can find the draft here: 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 <mailto: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.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brad Hilton) #11

+1. This makes a lot of sense.

···

On Thu, Mar 3, 2016 at 3:03 PM, Howard Lovatt <howard.lovatt@gmail.com> 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. :wink: 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
>.
>
> Thanks,
> Matthew
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


(Dave Abrahams) #12

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 <swift-evolution@swift.org> wrote:

On Thursday, 3 March 2016, Bradley Hilton via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','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. :wink: 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
>.
>
> Thanks,
> Matthew
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Erica Sadun) #13

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 <some unifying concept>", "This item can be converted to and from <some unifying concept>" and "This item can be represented as <some unifying concept>".

Best regards,

-- E

···

On Mar 3, 2016, at 6:42 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Thu Mar 03 2016, Howard Lovatt <swift-evolution@swift.org> 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 >> <javascript:_e(%7B%7D,'cvml','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. :wink: 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

.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
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


(Erica Sadun) #14

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 <matthew@anandabits.com> 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 <mailto: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 <mailto: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. :slight_smile:

You can find the draft here: 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 <mailto: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.

Thanks,
Matthew

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #15

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


(Matthew Johnson) #16

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


(Matthew Johnson) #17

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


(ilya) #18

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 <matthew@anandabits.com> > 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. :slight_smile:

You can find the draft here:
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
.

Thanks,
Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #19

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 <matthew@anandabits.com> 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.


(Erica Sadun) #20

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 <matthew@anandabits.com> 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