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.
Jordan > On Oct 6, 2017, at 15:25, Jordan Rose <[email protected]> wrote: > > 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 ever be a reason to write _fixed_layout in a source > package, and we wouldn't want this to become one. > > Jordan > > >> On Oct 6, 2017, at 15:23, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> Presumably, @_fixed_layout and its future formalized cousin would restore >> the current functionality? >> >> >> On Fri, Oct 6, 2017 at 16:32 Jordan Rose via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> While working on the non-exhaustive enums proposal I had it pointed out to >> me that structs 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: >> >> https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md >> >> <https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md> >> >> This one's way smaller than the enum one, and hopefully fairly >> uncontroversial. Feedback welcome! >> >> Jordan >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
