<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 6, 2017, at 10:17 AM, Benjamin Spratling via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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.<br class=""><br class="">I also like to use structs to support simple data models. Merely declaring properties and their types and getting synthesized initializers is great.<br class=""><br class="">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.<br class=""><br class="">Manually retyping the init method is tedious work which it's obvious the compiler already knows how to do.<br class=""><br class="">I suggest we add a way to explicitly mark synthesized init methods as public.<br class=""><br class="">Spell it however we want, perhaps something like this<br class=""><br class="">public init default<br class=""><br class="">Or<br class=""><br class="">public default init<br class=""><br class="">Or maybe just<br class=""><br class="">public init<br class=""><br class="">Whatever.<br class=""><br class="">Would someone like to help me draft a proposal for this?<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>You can find the proposal that was reviewed here: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md</a>.</div><div><br class=""></div><div>The core team’s decision rationale was very detailed and is also worth reading: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html</a>.</div><div><br class=""></div><div>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: <a href="https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md#interactions-with-other-features" class="">https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md#interactions-with-other-features</a>.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class="">-Ben Spratling<br class=""><br class="">Sent from my iPhone.<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>