> 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
