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

[Pyry Jahkola]

Taking the suggested changes into account, here's my review.

1) +1, I think this is a reasonable way for naming this family of protocols.

2) The problem isn't huge, but I think it's worth fixing. So far, the naming of stdlib protocols has been somewhat inconsistent in this regard.

3) I've used other languages & stdlibs with similar naming schemes, although none of them used the words "initializable" and "representable". Common alternatives have been word compositions involving expressions such as "convertible", "from", "to", "bi(jective)", "can build". However, I think "init" is so central in Swift that the use of "Initializable" is well justified. "Representable" is slightly less so but self-explanatory IMO, and more so than "convertible" which could be understood either or both ways.

4) Quick reading.

— Pyry

> On 13 May 2016, Matthew Johnson wrote:
> 
> While the community feedback on our SE-0041 proposal "Updating Protocol Naming Conventions for Conversions" (https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md <https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md>) has been positive about the need to establish conventions, feedback has been mixed to negative with regard to the specific conventions suggested in the proposal.
> 
> With that in mind, Erica and I have been working on refactoring those recommendations. We put together the following update and invite the community to bikeshed further with us. We hope this offers the Swift core team the flexibility to accept our proposal "with revision" if an alternative garners more support. With luck, we'll reach a naming consensus during the review period.
> 
> UPDATED APPROACH
> 
> Our updated approach focuses on the two most important conventions: one for initialization and one for representation.
> 
> 1. `Initializable`
> 
> `Initializable` designates protocols that convert *from* a type or from an associated type mentioned in the protocol name, such as the current `<Type>LiteralConvertible` protocols.  This convention would include member requirements for initializers, factory methods, and any other way an instance can be imported to establish a new instance of the conforming type.
> 
> For example, conforming to `ArrayLiteralInitializable` would allow a set to be created with `Set(arrayLiteral: <some array>)` and `var set: Set<T> = []`.
> 
> This phrase replaces the `Creatable` form from our original proposal.
> 
> 2. `Representable`
> 
> `Representable` designates protocols whose primary purpose is to project *to* a type or associated type mentioned in the protocol name.  Items in the standard library that would be subsumed into this naming include `CustomStringConvertible`, `CustomDebugStringConvertible`, and `RawRepresentable`, which we imagine would become `CustomStringRepresentable`, `CustomDebugStringRepresentable`, and (as current) `RawRepresentable`.
> 
> This second category groups together the `Convertible` and `Representable` categories from our original proposal and is predicated on the feedback from the design team review. The `Representable` designation does not promise bidirectional conversion although some `Representable` protocols may include requirements to allow attempted initialization *from* the type of the representation. Doing so falls outside the naming contract we are proposing. 
> 
> FUTURE DIRECTIONS
> 
> We did not include a third category for bidirectional conversion in this update. We recognize that style of contract is rare in Swift. Lossless conversion does not appear in the standard library outside of `RawRepresentable`, which we agreed was better covered by `Representable`. If such a convention is needed or adopted, we reserve the `Isomorphic` designation for future use.
> 
> Sent from my iPad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b88c8136/attachment.html>