+1 for the classification of the protocols to be renamed I completely agree that you can divide the protocols being examined into those categories and I appreciate the effort put in to doing so.
-1 for the names chosen ====== The new Representable is being applied to - CustomStringConvertible and CustomDebugStringConvertible. I wouldn’t be upset with calling these StringRepresentable and DebugStringRepresentable but I would argue that these are very specific protocols whose purpose is to create strings that can be used while debugging and while printing. We are not converting. We could argue that we're representing, but I would say we are using these protocols to describe an object. I would suggest naming them Describable and DebugDescribable The downside is that this isn’t extensible to other protocols that are creating instances but that isn’t really what’s being done here. These two are specific use cases. ===== The current RawRepresentable does, in my opinion, completely describe what it represents. Calling it Convertible is not, in my opinion, appropriate. The authors argue that it’s a preferred name because Convertible operates in both directions, but that isn’t the case with RawRepresentable. I can always ask a RawRepresentable instance for its rawValue but I will not always be able to successfully create a RawRepresentable instance from an arbitrary rawValue even if it is of the appropriate type. In fact, I think that their definition of Representable supports keeping RawRepresentable named as it is. RawRepresentable says to me that an instance can be represented by a rawValue of a specified type. We are not guaranteed that we can create an instance from this type. ====== Given the above two comments, there is no longer any confusion with the remaining types that are currently labeled Convertible that are in the proposed Creatable category. I don’t know that Convertible is the right word - Creatable might be better - but there doesn’t seem to be enough of a reason to change the existing name. I wouldn’t be upset with keeping these as Convertible or changing them to Creatable. ====== I’ve been thinking about these a lot. Last fall Greg Heo gave a great presentation about how to group the standard library protocols according to their names. The two that stick out for me are CustomStringConvertible and CustomDebugStringConvertible. One reason they stick out is the prefix “Custom”. The other is that we aren’t converting something - we are describing or representing. Daniel > On May 10, 2016, at 2:48 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of "SE-0041: Updating Protocol Naming Conventions for Conversions" > begins now and runs through May 16. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the review > manager. > > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the proposal? > * Is the problem being addressed significant enough to warrant a change > to Swift? > * Does this proposal fit well with the feel and direction of Swift? > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris Lattner > Review Manager > _______________________________________________ > 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
