[swift-evolution] Pitch: Restrict Cross-module Struct Initializers
tony.allevato at gmail.com
Fri Oct 6 17:04:38 CDT 2017
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 at 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:
> This one's way smaller than the enum one, and hopefully fairly
> uncontroversial. Feedback welcome!
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution