See: 
https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md

-Chris

> On Jan 30, 2017, at 1:26 AM, Charlie Monroe via swift-evolution 
> <[email protected]> wrote:
> 
> Unfortunately, I've come across this several times, but read here that it's 
> intended behavior. If I remember correctly, it has something to do with the 
> automatically generated initializers - it's implicitly internal so that you 
> don't expose the initializer by mistake.
> 
> The most annoying about it is, however, when the constructor has several 
> parameters - when you declare 
> 
>       public var text: String
> 
> Swift automatically generates an initializor that takes a text parameter, but 
> it is internal. When you have 4-5 members, the initializer gets quite long.
> 
> And if you want to have it public, you need to declare it and then assign 
> each member, which is tedious. I'd prefer some kind of an annotation on the 
> struct, for example:
> 
> @init(public)
> public struct SomeType { ... }
> 
>> On Jan 30, 2017, at 10:12 AM, David Sweeris via swift-evolution 
>> <[email protected]> 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.
>> 
>> - Dave Sweeris
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to