[swift-evolution] Public struct init is unexpectedly internal

[Matthew Johnson]

> On Jan 30, 2017, at 3:32 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 30, 2017, at 1:30 AM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>> 
>> 
>>> On Jan 30, 2017, at 1:21 AM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>> 
>>>> 
>>>> On Jan 30, 2017, at 1:12 AM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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. ;-)

I was the author of this proposal.  It was deferred.  The review brought a lot of good ideas to light so it will look somewhat different when it gets revived.  I have been assuming it is out of scope for Phase 1 but plan to revive it when the time comes.  

If this *is* in scope right now please let me know and I’ll find some time to start a new discussion thread outlining two possible directions we could take.

> 
> Slava
> 
>> 
>> - Dave Sweeris
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170130/e8e5ed17/attachment.html>