<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jul 6, 2016, at 6:47 PM, Scott James Remnant <<a href="mailto:scott@netsplit.com">scott@netsplit.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 6, 2016, at 4:34 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">To give you an example of the confusion, here is code made perfectly legal by SE-0025:</div><div class=""><br class=""></div><div class=""> public final class Example {</div><div class=""><br class=""></div><div class=""> overridable func foo() {}</div><div class=""><br class=""></div><div class=""> }</div></div></div></div></blockquote><div class=""><br class=""></div>I have no idea how you think this is related to SE-0025 (scoped access control). I also don’t understand why you think an `overridable` method in a `final` class would be legal under any proposal. That is nonsense and clearly in error.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div></div></blockquote><div><br class=""></div><div>SE-0117, which we are reviewing here, in its introduction introduces the new `subclassable` and `overridable` modifiers in a discussion about `public`, and indicates that they are used instead of that keyword. This to me strongly implies that these are in the same family as the access control modifiers.</div><div><br class=""></div><div>SE-0025 removes the error when the access of a member within a type is less restrictive, thus removes the error that would otherwise occur with the above code.</div></div></div></blockquote><div><br></div><div>SE-0025 says nothing about final though. I really don't think we would allow overridable in a final class in any case.</div><div><br></div><div>I do think it's fair to point out that details like is are not fully specified in the proposal and should be (in order to avoid another round of cleanup similar to what was necessary for SE-0025).</div><br><blockquote type="cite"><div><div><div><br class=""></div><div><br class=""></div><div>Consider this another strong argument for keeping access and inheritability separate, the following code would be obviously an error/warning since `open` makes no sense within a `final` class:</div><div><br class=""></div><div> public final class Example {</div><div><br class=""></div><div> public open func foo() {}</div><div><br class=""></div><div> }</div><div><br class=""></div><div>Clarity is always a goal for Swift. This to me has more of it than replacing `public`.</div><div><br class=""></div></div>Scott</div></blockquote></body></html>