[swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Matthew Johnson]

> On Jan 4, 2016, at 11:31 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> I was guessing that the current proposal does not change anything re. default and current member wise initializers and so in addition to suggesting Scala syntax I was also suggesting the transformation shown, or its equivalent. The advantage of having a member wise init that has default arguments and argument labels are considerable:
> 
> 1. Allows lets as well as vars 

The proposal does allow lets as well as vars.  It is very unfortunate that defaults for lets cannot be supported immediately.  Doing that is a highly desired enhancement.  If you read Chris Lattner’s comments in the history of this thread you will have more background on the issues involved.

> 2. Allows partial custom initialization 

I don’t know for sure what you mean by this but the proposal does allow partial custom initialization in the way I think of that phrase.

> 3. Eliminates need for other mechanisms, i.e. default and existing member wise initialization  
> 
> These facilities could be added to `memberwise init(...)` as well. In particular, if a member wise init was present then an initialized property could have a label, e.g.:

I do not think allowing custom labels for memberwise initialization parameters is a good idea.  The caller is initializing a member directly.  It is more clear if the name of the parameter matches the name of the parameter.

> 
>      class C {
>          let example name: Type = initial
>          memberwise init(...)
>      }
> 
> Would become the equivalent of:
> 
>      class C {
>          let name: Type
>          init(example name: Type = initial) {
>              self.name <http://self.name/> = name
>          }
>       }
> 
> The Scala syntax is just a shorter alternative, ideally there be a discussion of the pros and cons of the two syntax that included the possibility of the wider set of objectives as outlined in the numbered points above.

It was not a goal of this proposal to provide the most concise syntax for simple cases.  The goal of this proposal is to provide a flexible and scalable memberwise initialization facility.  Specific goals included supporting more than one memberwise initializer as well as allowing some properties to be memberwise initialized and some (private state, etc) to be initialized by other means.

An independent proposal focused on making simple cases as concise as possible is something that could also be pursued.

> 
> On Tuesday, 5 January 2016, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
>> On Jan 4, 2016, at 5:48 PM, Howard Lovatt <howard.lovatt at gmail.com <javascript:_e(%7B%7D,'cvml','howard.lovatt at gmail.com');>> wrote:
>> 
>> Yes you can get close, but:
>> 
>> 1. Its weird that you can only do this in an extension.
> 
> This is the way the current implicit initializer works.  It is not synthesized if you define any initializers in the body of the type.  There are good reasons it works this way and the current proposal does not change those rules.
> 
>> 2. Its not quite the same as the proposal the current member-wise initialiser does not make the init arguments optional (the arguments themselves do not have defaults), i.e. with your example `let defaultOriginRect = Rect(size: Size(width: 5.0, height: 5.0))` fails whereas it would work for the proposal (this could also be true if the existing struct memberwise init and the new `memberwise init(..)` where changed to provide init argument defaults).
> 
> The implicit memberwise initializer currently in the language does not provide defaults for parameters.  This proposal changes that behavior and provides defaults if the the member is a `var` and has an initial value.  
> 
> Unfortunately I was not able to find a solution to allow synthesized parameters for `let` members to have default values.  This is because the current semantics for `let` members do not allow the member to be initialized to anything other than the initial value if one is provided.  I am hoping a solution to this will be identified in the future and have suggested one possible mechanism `@default` in the future enhancements section.
> 
>> 3. Only ‘really' works for structs, the compiler doesn’t write a member-wise initialiser for classes (just a default initializer).
> 
> That is true about the current behavior of the language but is not true with regards to the current proposal.
> 
>> 4. Still need the compiler to provide both default and member-wise initialisers, whereas this proposal would allow the existing default and member-wise initialisers to be deprecated and just the new member-wise initialiser would remain which would simplify the language and make it clear what was happening (this could also be true if a `memberwise init(..)` where added and existing compiler written inits removed).
> 
> This proposal does not change anything with regard to the default initializer.
> 
>> 
>> 
>>> On 5 Jan 2016, at 10:16 AM, Matthew Johnson <matthew at anandabits.com <javascript:_e(%7B%7D,'cvml','matthew at anandabits.com');>> wrote:
>>> 
>>> struct Rect { var origin: Point = Point(), size: Size = Size() }
>>> extension Rect {
>>>        init(center: Point, size: Size) {
>>>            let originX = center.x - (size.width / 2)
>>>            let originY = center.y - (size.height / 2)
>>>            self.init(origin: Point(x: originX, y: originY), size: size)
>>>        }
>>> }
>> 
> 
> 
> 
> -- 
>   -- Howard.
> 

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