<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="">Thank you for taking the time to put together this summary and analysis Erica! <div class=""><br class=""></div><div class="">In thinking about this further I am not convinced that separating the initializer and factory method variants into separate conventions is a good idea. If we do that it would raise a question as to whether we should also have variations of the bidirectional protocol for both initializers and factory methods and I think that is going to far. So I am currently leaning towards sticking with three conventions.</div><div class=""><br class=""></div><div class="">If we do that I definitely lean towards Creatable. While initializers do not create an instance directly an instance is created every time they are used (leaving failable and throwing initializers aside for sake of discussion). Calling an initializer <b class="">does</b> “produce something new and cause it to exist”. It seems appropriate to me. An alternative might be Constructible, however that doesn’t seem appropriate in Swift as it implicitly references “constructor” in a programming context.</div><div class=""><div class=""><div class=""><br class=""></div><div class="">BTW, the factory method case seems especially important to consider in the context of the problems with retroactively conforming classes in Foundation and other Apple frameworks to protocols which include object instantiation. It isn’t clear yet how that problem will be solved and it is possible that we may see a solution that works for factory methods sooner than (or in lieu of) a solution that works for initializers. The factory method case is potentially more tractable because the return type is specified in the function declaration rather than being implicit.</div><div class=""><br class=""></div><div class="">Matthew</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 6:30 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><b class="">Terms currently on the table:</b></div><div class=""><div class=""><ul class=""><li class="">can be initialized from: <font face="Courier" class="">Instantiable, Initializable, Establishable</font></li><li class="">can build via factory method: <font face="Courier" class="">Creatable, Building, Producer/Producing, Establishable</font></li><li class="">can be converted to: <font face="Courier" class="">Representable, Expressible, Presentable, Projectable</font></li><li class="">can be represented as and instantiated by: <font face="Courier" class="">Convertible, Representable</font></li></ul></div></div><div class=""><br class=""></div><div class="">I'm going to courteously disagree with Brent ("I actually think `Representable` better implies two-way than `Convertible` does"). Here's my reasoning. <b class="">Convertible</b> implies a commutative or two-way relation. For example, a convertible car can be converted to a sedan style or an open style. A convertible sofa can act as a bed or a sofa. Convertible suggests <b class="">a R b</b> as well as<b class=""> b R a</b>. The word means to change into a different form and be used in a different way. </div><div class=""><br class=""></div><div class="">To <b class="">represent</b> means to serve as or to take the place of by accruing characteristics or qualities. This suggests that <b class="">a R b</b> is <i class="">not</i> the same as <b class="">b R a</b>. My lawyer can represent my legal interests but I cannot represent my lawyer in court. </div><div class=""><br class=""></div><div class="">To <b class="">create</b> means to produce something new and cause it to exist. This is semantically distant from <b class="">initializing</b>. The current (badly named) IntegerLiteralConvertible means "a conforming construct can use an integer literal to establish an instance of itself". There are, as Matthew points out two tasks that might arise through protocols: the creation of an instance through a factory method and the creation an instance by passing a separate type to an initializer.</div><div class=""><br class=""></div><div class="">The latter case is what we see throughout and commonly in the current Swift standard library: <font face="Courier" class="">A.init(b) -> a</font>. Of the words that have been brought up so far, to <b class="">instantiate</b> and to <b class="">initialize</b> are the only two that describe this task. I do not believe this is well described as conversion.</div><div class=""><br class=""></div><div class="">I assume the factory style is <font face="Courier" class="">A.staticMethod(...) -> a</font>. In such case, I've collected your suggestions plus a few others above.</div><div class=""><br class=""></div><div class="">Of these, I most prefer initializable (<font face="Courier" class="">DoubleLiteralInitializable</font>), convertible (<font face="Courier" class="">RawConvertible</font>, <font face="Courier" class="">StringLiteralConvertible</font>), and representable (<font face="Courier" class="">CustomStringRepresentable</font>). I have no particular feelings about factory methods at this time.</div><div class=""><br class=""></div><div class="">Finally, I grabbed the following from a quick search of release notes, just to get a sense that protocol renaming does happen:</div><div class=""><ul class=""><li class="">LogicValue became BooleanType</li><li class="">Printable and DebugPrintable became CustomStringConvertible, CustomDebugStringConvertible</li><li class="">ExtensibleCollectionType was folded into RangeReplaceableCollectionType</li></ul></div><div class=""><br class=""></div><div class="">-- Erica</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 4:40 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I really like Creatable for the first as it is general enough to handle initializers an factory methods. Great idea! Alternatively, we could use that for a fourth category covering factory methods and stick with Initializable for the first case.<br class=""><br class=""><blockquote type="cite" class="">On Dec 15, 2015, at 5:30 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">resentable is probably a lot better than CustomStringRepresentationExpressible<br class=""></blockquote><br class="">Representable is what I would have used if I wasn't trying to make a minimal change or if RawRepresentable didn't already use it for bidirectional conversion, so I agree that it is better than both Expressible and Projectable.<br class=""></blockquote><br class="">Let's run with the idea that everything is up for grabs and that better names will better serve the developer community in the long run. In such a case, if the core naming patterns were established as Convertible for bidirectional conversion, would RawConvertible be such a bad thing?<br class=""></blockquote><br class="">I actually think `Representable` better implies two-way than `Convertible` does. A representation is a way of expressing something in a different form; a conversion is a specific act of transforming one thing to another. To me, the former sounds more like a round trip than the latter.<br class=""><br class="">So I suggest:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol IntegerLiteralInitializable {...} // or maybe ‘Creatable’, to cover the factory method case?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol RawRepresentable {…}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol CustomStringConvertible {…}<br class=""><br class=""></blockquote><br class=""><br class=""><br class=""></div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAdXaHq9yPB0fH-2BU2gg6ekWrLky9sAE9JsroxVLHOu8NtQwoRnVUT6ZqUr2ezot3e1RdBbzWjDFI6UNmZozKXDvwDs-2BWdybKoIA2w8hQ6bMIo0KG1Lz9Jx1-2FTUlqUz05KE37Ax3QeR9r4JnE6prtnLqlYmrWwYABYNthp5ss3-2B0X8f6RlDz8Hf9aIC82Jcv6VJY-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</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></div></div></body></html>