<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Thanks for bringing this up. I thought of this only after posting the proposal, and I think the answer <i class="">ought</i> 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.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 8, 2017, at 12:49, Rudolf Adamkovič via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">This is a great proposal.<div class=""><br class=""></div><div class="">However, it can make unit testing problematic. Let me explain.</div><div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div><div class="">Would the rules described in this proposal be enforced also for testing targets/modules?</div><div class=""><br class=""></div><div class="">R+<br class=""><br class=""><div class="">Sent from my iPhone</div><div class=""><br class="">On 7 Oct 2017, at 23:44, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">While working on the non-exhaustive enums proposal I had it pointed out to me that <i class="">structs</i> 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:<div class=""><br class=""></div><div class=""><a href="https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md" class="">https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md</a></div><div class=""><br class=""></div><div class="">This one's way smaller than the enum one, and hopefully fairly uncontroversial. Feedback welcome!</div></div></div></blockquote><br class=""></div><div class="">Great catch, +1 to the proposal!</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>