> On Jan 30, 2017, at 1:30 AM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Jan 30, 2017, at 1:21 AM, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>> >>> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> So I’ve got this code in a package called “SomeLib": >>> public struct SomeType { >>> public var text = "SomeText" >>> } >>> and then, in another package, write this: >>> import SomeLib >>> print(SomeType().text) >>> and then run swift build, I get this error: >>> error: 'SomeType' initializer is inaccessible due to 'internal' protection >>> level >>> >>> "Well that’s odd… there isn’t even an initializer to be internal or >>> public”, I said to myself. Then I proceeded to futz around with it for a >>> while before having a lightbulb moment: >>> public struct SomeType { >>> public var text = "SomeText" >>> public init() {} //this fixes it >>> } >>> >>> >>> In cases like this where the struct is public and all its stored properties >>> are both public and already have values, should we make the implicit init() >>> function also be public? Seems like the “least surprising” thing to do. >> >> This is intentional. I believe the core team’s rationale is that public APIs >> should always be explicitly written down in source. So your example above >> defining a public init() is correct. > > Oh, I knew (well, suspected) it was intentional… I just didn't recall if we’d > discussed this specific scenario before. If we did, then I don’t want to > rehash it.
I think there was a proposal floating around for ‘flexible member-wise initialization’. This would allow explicitly defining an initializer (to make it public or @_inlineable or whatever) without writing out the boilerplate to initialize all members. I don’t have the link offhand, and I don’t remember what the conclusion was, but if you’re interested you might want to look into it and revive it. ;-) Slava > > - Dave Sweeris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
