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

[Matthew Johnson]

> On Jan 7, 2016, at 1:23 PM, David Owens II <david at owensd.io> wrote:
> 
> 
>> On Jan 7, 2016, at 10:49 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> 
>>> On Jan 7, 2016, at 12:37 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 
>>> 
>>>> On Jan 7, 2016, at 10:32 AM, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>>>> 
>>>> And this is more clear than this?
>>>> 
>>>> class Foo {
>>>>   var x,y,z: Int
>>>>   init(x: Int, y: Int, z: Int) {
>>>>     self.x = x
>>>>     self.y = y
>>>>     self.z = z
>>>>   }
>>>> }
>>> 
>>> No, it isn't, but Matthew asked… I'm personally not too motivated to support anything more than all-or-nothing memberwise initialization, and tend to agree that anything more specialized deserves an explicit implementation.
>> 
>> Maybe you would feel differently if you were an app developer.  Different kinds of code have different needs.  The most important use cases I have in mind are related to UI code, which is often the majority of the code in an app.
>> 
>> Matthew
> 
> It’s not a universal truth that the majority of code in an app is UI code, unless you’re specifically talking about really small apps or essentially apps that are views for a server. The UI code to non-UI code ratio in a product like Word (for Mac) is no where near “majority”.

I did say “often”, not always.  I didn’t make a claim to any universal truth.

Also, by “app” I meant typical consumer mobile apps that make up most of the stuff on the app store aside from games.  I did not mean to refer to software in general.  I could have been more clear about that.

> 
> -David

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