> On Jan 30, 2017, at 1:21 AM, Slava Pestov <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.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
