> On Oct 7, 2017, at 14:44, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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! > > Great catch, +1 to the proposal! > > Please add the point Xiodi mentions to the writing though so that the review > cycle adequately discusses it. A "fragile struct” (for some definition of > fragility), but definitely including C structs, will have knowable stored > properties, and it isn’t clear that these should be subjected to this > restriction. The win of the restriction in that case is the invariant point > you’re making. It is best to address this head-on in the writing, and > mention the alternate approach in the ‘alternatives considered’ section > (along with why you think you’ve picked the right choice).
Good call. Updated the Alternatives Considered section with my response to Xiaodi, plus a specific section on C structs. (Also added the @testable part that Rudolf mentioned.) Initial implementation has also been posted. Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
