<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 23, 2017, at 11:21 AM, 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=""><span 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; float: none; display: inline !important;" class="">1) Allow stored properties in same-module extensions. &nbsp;This has been discussed in the past and is a possibility, but I suspect it is not in scope for consideration during Swift 4.</span></div></blockquote></div><br class=""><div class="">Allowing stored properties and overridable methods in same-*file* extensions would be trivial to implement.</div><div class=""><br class=""></div><div class="">Same-module extensions are still tricky to generalize because in non-WMO mode, the class (and its metadata, such as stored property layout and vtable) could be emitted in a different translation unit than the extension, so we’d have to ’stitch’ together the definitions somehow and deal with the lack of static knowledge of things like the size of the class and the virtual methods it defines.</div><div class=""><br class=""></div><div class="">Slava</div></body></html>