<div dir="ltr">Yes, this feels right. I was a little unsure/unclear about this at first, but the example with `let` and invariants convinced me, and now I can see how changing a stored property to a computed property later could cause problems in your scenario.<div><br></div><div>So even though *technically* there is some subset of structs (PODs, mainly) where creating extra-module initializers could feasibly work, I think it makes complete sense to align with classes here because what we want to say is that &quot;the only person who knows enough about a type to initialize it is the module who defines it; anyone else should have to go through them to get an instance&quot;.</div><div><br></div><div>Strong +1 from me.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 6, 2017 at 2:32 PM Jordan Rose via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">While working on the non-exhaustive enums proposal I had it pointed out to me that <i>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&#39;s half the point of computed properties—and it&#39;s also important for a struct author to be able to enforce invariants across the struct&#39;s properties. So after talking to a few other Apple Swift folks I put together this proposal:<div><br></div><div><a href="https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md" target="_blank">https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/nnnn-restrict-cross-module-struct-initializers.md</a></div><div><br></div><div>This one&#39;s way smaller than the enum one, and hopefully fairly uncontroversial. Feedback welcome!</div><div><br></div><div>Jordan</div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>