[swift-evolution] Pitch: Restrict Cross-module Struct Initializers

[Tony Allevato]

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:
>
>
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171006/e16c55db/attachment.html>