This is a great proposal. However, it can make unit testing problematic. Let me explain.
In my unit tests, I often add initializers that set stored properties directly to create structs with desired data and those are then fed into the struct that’s under test. This is to test in complete isolation, without invoking the “production” initializer of structs that aren’t under test. In other words, I want to avoid invoking any behavior of structs that aren’t directly under test. Would the rules described in this proposal be enforced also for testing targets/modules? R+ Sent from my iPhone > On 7 Oct 2017, at 23:44, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution >> <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 >> >> 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). > > -Chris > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
