[swift-evolution] explicitly mark synthesized init as public

[Matthew Johnson]

> On Jul 6, 2017, at 10:17 AM, Benjamin Spratling via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Often I want to separate my data model into a separate framework from my UI.  This enables separation of data and logic tests from UI tests.  And sharing a common data model between multiple apps, such as a end-user facing app and a back-of-house app.
> 
> I also like to use structs to support simple data models.  Merely declaring properties and their types and getting synthesized initializers is great.
> 
> But when a struct is declared in one framework and it's init method is called from another, the compiler does not allow access to this synthesized initializer.
> 
> Manually retyping the init method is tedious work which it's obvious the compiler already knows how to do.
> 
> I suggest we add a way to explicitly mark synthesized init methods as public.
> 
> Spell it however we want, perhaps something like this
> 
> public init default
> 
> Or
> 
> public default init
> 
> Or maybe just
> 
> public init
> 
> Whatever.
> 
> Would someone like to help me draft a proposal for this?

I wrote a pretty comprehensive proposal for improving initializer synthesis early last year.  This proved to be a complex topic.  Our understanding of the design space continued to evolve through the review process resulting in a decision to defer the proposal.  I plan to return to the topic when it is considered in scope for a Swift release theme.

You can find the proposal that was reviewed here: https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md>.

The core team’s decision rationale was very detailed and is also worth reading: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html>.

After the review I wrote a proposal for partial initializers which includes an appendix summarizing the design space and includes my thoughts about how to move forward when we return to the topic: https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md#interactions-with-other-features <https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md#interactions-with-other-features>.

> 
> 
> -Ben Spratling
> 
> Sent from my iPhone.
> _______________________________________________
> 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/20170706/0fa697e1/attachment.html>