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

Matthew Johnson matthew at anandabits.com
Wed May 18 07:21:29 CDT 2016



Sent from my iPad

On May 17, 2016, at 11:32 PM, Brent Royal-Gordon <brent at architechies.com> wrote:

>> 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.
> 
> If we're doing this, I wonder if category 1 shouldn't just be `Convertible`. This would preserve our `LiteralConvertible` protocols with the same names (which, consistency issues aside, seem perfectly cromulent), while shifting the `StringConvertible` protocols over to the `Representable` category.

Do you really think 'Convertible' is more clear than 'Initializable'?

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 



More information about the swift-evolution mailing list