Thanks for bringing this up. I thought of this only after posting the proposal, and I think the answer ought to be "you're exempt from this restriction if you use `@testable import`". I still want to work out that this is implementable even for future frameworks with binary compatibility concerns (though the testable-only parts don't have to be a binary-compatible interface), but you're right that the proposal isn't really complete without that exception. I'll add it today.
Jordan > On Oct 8, 2017, at 12:49, Rudolf Adamkovič via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 <mailto:swift-evolution@swift.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). >> >> -Chris >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
