> On Jan 4, 2016, at 11:31 PM, Howard Lovatt <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On Jan 4, 2016, at 5:48 PM, Howard Lovatt <[email protected]
>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected]
>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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.
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
