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]> 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
