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.
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 "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". Strong +1 from me. On Fri, 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! > > Jordan > _______________________________________________ > 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
