<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Oh, sorry, the missing piece of that is 'inlinable': an inlinable memberwise initializer in a fixed-layout struct should have no performance overhead in an optimized build.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 6, 2017, at 15:25, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@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; line-break: after-white-space;" class="">Good question. Slava and I talked about that and decided that there wasn't much point. '_fixed_layout' still doesn't cover the invariant problem, and memberwise initializers are really common when that's not relevant. We don't think there should <i class="">ever</i> be a reason to write _fixed_layout in a source package, and we wouldn't want this to become one.<div class=""><br class=""></div><div class="">Jordan<br class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 6, 2017, at 15:23, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">Presumably, @_fixed_layout and its future formalized cousin would restore the current functionality?</div><div dir="auto" class=""><br class=""></div><div class=""><br class=""><div class="gmail_quote"><div class="">On Fri, Oct 6, 2017 at 16:32 Jordan Rose 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;line-break:after-white-space" class="">While working on the non-exhaustive enums proposal I had it pointed out to me that <i class="">structs</i> actually currently leak implementation details across module boundaries, specifically their full set of stored properties. This only comes up in one place: when making an initializer for the struct in an extension in another module. We really want people to be able to change the stored properties in their structs between releases without it being a source break—that's half the point of computed properties—and it's also important for a struct author to be able to enforce invariants across the struct's properties. So after talking to a few other Apple Swift folks I put together this proposal:<div class=""><br class=""></div><div class=""><a href="https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md" target="_blank" class="">https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md</a></div><div class=""><br class=""></div><div class="">This one's way smaller than the enum one, and hopefully fairly uncontroversial. Feedback welcome!</div><div class=""><br class=""></div><div class="">Jordan</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>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>