<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=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 1:38 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 11:48 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</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=""><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 9:15 AM, Javier Soto <<a href="mailto:javier.api@gmail.com" class="">javier.api@gmail.com</a>> wrote:</div><div class="">How would we evaluate the proposal to introduce the "sealed" specifier for classes (open within module, final outside of module) and default to that, in terms of source-code compatibility? <br class="">From my point of view it might be easier to do before Swift 3, but if delayed until Swift 4 it wouldn't be the most time-consuming breakage for developers. <br class=""></div></blockquote><div class=""><br class=""></div><div class="">I believe we consider this plan of record, actually, other than the spelling of the modifier. It's something we probably ought to commit to in Swift 3, though.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">By “commit to in Swift 3” do you mean that it is likely the core team would introduce a proposal for this in Swift 3?</div></div></div></div></blockquote><div><br class=""></div>We might be able to put the decision off as part of the larger resilience feature, but I think it would be better to settle this in 3 if we can. Who, exactly, authors the proposal is not settled; a community proposal would be welcome.</div><div><br class=""></div><div>John.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">John.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 22, 2016 at 9:09 AM Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 10:59 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 8:17 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap:break-word" class=""><div class=""><ul class=""><li class="">Rationalizing base conversion protocol names. I personally don't have the heart to try to re-address the "LiteralConvertible" protocol naming thing again but this would be the last chance to do anything about getting this issue addressed.</li></ul></div></div></blockquote><div class="">Given the vast amount of bike shedding that has already happened around this topic, I don’t think there is a solution that everyone will be happy with. It is also unclear (to me at least) what solution might be acceptable to the core team. </div></div></div></div></blockquote><div class=""><br class=""></div>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.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">This is orthogonal to the discussion that happened in your thread, definitely no discussion of any changes to the requirements. :)</div><div class=""><br class=""></div><div class="">We are discussing this proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a> and specifically the use of the `Convertible` suffix for both the `*LiteralConvertible` protocols and the `Custom(Debug)StringConvertible` protocols where the conversion runs in opposite directions.</div><div class=""><br class=""></div><div class="">The core team decision was:</div><div class=""><br class=""></div><div class="">"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."</div></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">At the same time, it continues to bother me that `Convertible` is used by standard library protocols with two completely different meanings. This is a problem that deserves to be solved and as it involves a breaking change Swift 3 is the right timeframe in which to do so.</div><div class=""><br class=""></div><div class="">If the core team is able to indicate an approach they favor I would be willing to revise and resubmit the proposal. But I don’t want to spend any further time speculating about what solution might be considered acceptable.</div><div class=""><br class=""></div><div class="">Matthew</div></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div><div dir="ltr" class="">-- <br class=""></div><div data-smartmail="gmail_signature" class=""><div dir="ltr" class="">Javier Soto</div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>