[swift-evolution] Pitch: Restrict Cross-module Struct Initializers

[Jordan Rose]

> On Oct 7, 2017, at 14:44, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
>> On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171009/e3feb959/attachment.html>