<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I appreciate your rework on this - I still don’t understand one thing and disagree with a second:<div class=""><br class=""></div><div class="">(1) I don’t understand what the word “Custom” adds to CustomStringRepresentable and CustomDebugStringRepresentable and would drop that prefix (even if it remains Convertible).</div><div class=""><br class=""></div><div class="">(2) The use case for these two still stands out from every other protocol on the list. The intent is (was) better captured by “Describable”. i.e. these are things for which there is a description. I think it is more descriptive to name them Describable and DebugDescribable.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Daniel<br class=""><div><blockquote type="cite" class=""><div class="">On May 13, 2016, at 12:31 PM, Matthew Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">While the community feedback on our SE-0041 proposal "Updating Protocol Naming Conventions for Conversions" (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a>) 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.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">UPDATED APPROACH</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Our updated approach focuses on the two most important conventions: one for initialization and one for representation.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">1. `Initializable`</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">`Initializable` designates protocols that convert *from* a type or from an associated type mentioned in the protocol name, such as the current `&lt;Type&gt;LiteralConvertible` protocols. &nbsp;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.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">For example, conforming to `ArrayLiteralInitializable` would allow a set to be created with `Set(arrayLiteral: &lt;some array&gt;)` and `var set: Set&lt;T&gt; = []`.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">This phrase replaces the `Creatable` form from our original proposal.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">2. `Representable`</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">`Representable` designates protocols whose primary purpose is to project *to* a type or associated type mentioned in the protocol name. &nbsp;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`.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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.&nbsp;</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">FUTURE DIRECTIONS</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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.</span></div><br class="">Sent from my iPad</div><div class=""><br class="">On May 10, 2016, at 7:51 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On May 10, 2016, at 11:48 AM, Chris Lattner &lt;<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>&gt; wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Hello Swift community,</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">The review of "SE-0041: Updating Protocol Naming Conventions for Conversions" begins now and runs through May 16. The proposal is available here:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""> &nbsp; &nbsp;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a></span><br class=""></blockquote><span class=""></span><br class=""><span class="">Here are comments from someone who preferred to stay anonymous. &nbsp;These are not my own:</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">* What is your evaluation of the proposal?</span><br class=""><span class=""></span><br class=""><span class="">I rather agree with the comments mentioned in the proposal from the Standard Library design team, in that I agree with the basic intention of the proposal, but I’m not convinced about the proposed answer. Specifically:</span><br class=""><span class=""></span><br class=""><span class="">1) I agree with the proposal that Representable seems more suited to meaning “a representation can be created from this type”. This is in line with existing Cocoa APIs that use “dictionaryRepresentation” to generate a dictionary that represents the object (for e.g. serialization to JSON). See, for example, NSUbiquitousKeyValueStore, NSUserDefaults, and SCNTechnique. Out of those, only the last one can also be initialized from a dictionary, so the term “representation” as used in existing Cocoa frameworks seems better suited for implying only a one-way conversion (and also feels natural to me).</span><br class=""><span class=""></span><br class=""><span class="">2) I’m not convinced on Creatable. I’ve been using Convertible for protocols that imply that the type can be initialized from another type (e.g. the DictionaryConvertible protocol would contain init(dictionary:), and thus SCNTechnique would conform to it). This also seems in line with the bulk of the “Convertible” protocols in the standard library today. The word “creatable" strikes me as strange, because the term “create” isn’t used anywhere else in regards to initialization that I know of.</span><br class=""><span class=""></span><br class=""><span class="">3) I’m not positive that we need a third protocol that implies bidirectionality. I’m not opposed to it, but if raw values conformed to both RawConvertible and RawRepresentable to indicate both their initialization and generated representation qualities, I’d be fine with that. And then maybe there’s just a typealias for RawValueProtocol that combines those for convenience.</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">* Is the problem being addressed significant enough to warrant a change to Swift?</span><br class=""><span class=""></span><br class=""><span class="">Yes, in that I think it would be good to establish a clear convention here and stick to it. Whether the “Creatable” term is sufficiently clear to warrant a renaming of all the “Convertible” protocols, I’m not as sure about. I think at least CustomStringRepresentable and CustomDebugStringRepresentable would be worth doing since they imply a different direction from all the other “Convertible" protocols.</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">* Does this proposal fit well with the feel and direction of Swift?</span><br class=""><span class=""></span><br class=""><span class="">Yes, insofar as Swift generally seems to value predictability and consistency, and this would improve upon that.</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br class=""><span class=""></span><br class=""><span class="">The most relevant library here I think is the Cocoa libraries, as mentioned above, which are already using the term “representation” to mean a one-way conversion to another type.</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br class=""><span class=""></span><br class=""><span class="">I’ve been thinking about this for a while with regards to dictionary serialization, because it’s so common for data models, but I haven’t necessarily thought through all the implications for e.g. raw values.</span><br class=""><span class=""></span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>