explicitly mark synthesized init as public


(Benjamin Spratling) #1

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?

-Ben Spratling

···

Sent from my iPhone.


(Matthew Johnson) #2

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.

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.

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.

···

On Jul 6, 2017, at 10:17 AM, Benjamin Spratling via swift-evolution <swift-evolution@swift.org> wrote:

-Ben Spratling

Sent from my iPhone.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution