[swift-evolution] Revisiting SE-0041 Names

Erica Sadun erica at ericasadun.com
Wed Jun 22 13:04:36 CDT 2016

Proposal: 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>

Rejection: "The feedback on the proposal was generally positive about the idea of renaming these protocols, but the specific names in the proposal are not well received, and there is no apparent confluence in the community on better names.  The core team prefers discussion to continue -- if/when there is a strong proposal for a better naming approach, we can reconsider renaming these."

John McCall: "To be clear, I don't care about the name.  If you want to rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't drag the conversation into the muck again. :)  It's the design of the requirements that I'm pretty opposed to revisiting."

The Problem: This is really the last chance to rationalize this across the language and to evaluate whether other protocol groups should have a core scheme for naming.

Type I: A protocol for types that can be initialized from specific types or protocols, e.g. created/initialized with strings (a specific type) or created/initialized with floating point numbers (conforming to a protocol). Current examples include "IntegerLiteralConvertible".
Type II: A protocol for types that can form a representation which may or may not provide a complete projection (the original may not be recoverable from that representation), e.g. "CustomStringConvertible" and "CustomPlaygroundQuickLookable" both fall into this. 
Type III: A protocol for isomorphism: can be converted to and from a type, e.g. "RawRepresentable"

Existing Protocols:

AbsoluteValuable, AnyCollectionProtocol, AnyObject, ArrayLiteralConvertible, BidirectionalCollection, Collection, BidirectionalIndexable, BinaryFloatingPoint, FloatLiteralConvertible, BitwiseOperations, Boolean, BooleanLiteralConvertible, CVarArg, Collection, Sequence, Comparable, CustomDebugStringConvertible, CustomLeafReflectable, CustomPlaygroundQuickLookable, CustomReflectable, CustomStringConvertible, DictionaryLiteralConvertible, Equatable, ErrorProtocol, ExtendedGraphemeClusterLiteralConvertible, FloatLiteralConvertible, FloatingPoint, IntegerLiteralConvertible, SignedNumber, AbsoluteValuable, Strideable, Hashable, Indexable, IndexableBase, Integer : _Integer, Strideable, IntegerArithmetic : _IntegerArithmetic, Comparable, IntegerLiteralConvertible, IteratorProtocol, LazyCollectionProtocol, LazySequenceProtocol, LazySequenceProtocol, MirrorPath, MutableCollection, Collection, MutableIndexable, NilLiteralConvertible, OptionSet, RawRepresentable, OutputStream, RandomAccessCollection, BidirectionalCollection, RandomAccessIndexable, RangeReplaceableCollection, Collection, RangeReplaceableIndexable, RawRepresentable, Sequence, SetAlgebra, ArrayLiteralConvertible, SignedInteger : _SignedInteger, Integer, SignedNumber, IntegerLiteralConvertible, Streamable, Strideable, StringInterpolationConvertible, StringLiteralConvertible, UnicodeCodec, UnicodeScalarLiteralConvertible, UnsignedInteger : _DisallowMixedSignArithmetic, Integer, _DisallowMixedSignArithmetic : _Integer, _Incrementable, _Integer, CustomStringConvertible, Hashable, IntegerArithmetic, BitwiseOperations, _Incrementable, _IntegerArithmetic, _SequenceWrapper, _SignedInteger : _Integer, SignedNumber

Names (see: https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg <https://pbs.twimg.com/media/Ck8TUt0UkAAX1Im.jpg>)

Type I: Initializing
Type II: Representable
Type III: Isomorphic

Here's a paint brush. Have at it. And keep in mind the API-isms like "use nouns" (e.g. Sequence vs SequenceType) and "ing" (e.g. Initializing vs Initializable)

-- E

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

More information about the swift-evolution mailing list