> On Jul 6, 2017, at 10:17 AM, Benjamin Spratling via swift-evolution 
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to