[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Matthew Johnson]

> On Jan 8, 2016, at 10:09 AM, Tal Atlas <me at tal.by> wrote:
> 
> It’s a common use case to have a private stored object that’s set externally via the initializer, I think having a solution that doesn’t support that would be a big mistake.

IMO it would bad to expose a private property via an internal or public initializer without a specific request from the programmer to do that.  I believe the best approach to address this is to allow access control for init: `private public(init)`.  

Chris really wanted the initial proposal to focus on core functionality that can be enhanced later, with independent review of the enhancements, even if those enhancements make it into Swift 3.  That is what this proposal reflects.  

In the meantime, you can still do what you want using a memberwise initializer that manually accepts additional parameters for the private properties.  That might not be ideal, but at least you can still use memberwise initialization for other properties.

Matthew

> 
> On Fri, Jan 8, 2016 at 11:08 AM Tal Atlas <me at tal.by <mailto:me at tal.by>> wrote:
> My biggest problem is what does member wise even mean the averts person. And a naked ... Is a spread operator in most languages and doesn't mean anything inherently. 
> 
> I worry about arguing about the specifics because this is way better than the current state but I very much think the details of this proposal are confusing to the average developer and is more restrictive to any future use of the spread operator. 
> 
> On Thu, Jan 7, 2016 at 8:25 PM Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > We will probably have warning flags eventually.
> 
> I don't know what makes you think so. The language has so far carefully avoided this, and we've heard some pretty strong statements from the core team against the idea of compiler flags and incompatible dialects.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

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