[swift-evolution] a few initializer proposals

[Robert Bennett]

I think an even stronger change should be made for #1: instead of explicitly opting into not discarding the default initializer, you should have to explicitly opt out of keeping it with something like @nosynthesizedinit. Unless I’m missing something and there is a compelling reason to remove the default initializer when you’ve provided another initializer.

I agree with #2 as is.

For #3, I imagine there’s some reason classes don’t get synthesized initializers. Probably because they’re meant to encapsulate a lot more functionality than merely maintaining state. Even if a class had an init with the “default” signature, it would almost certainly do more in the body than just assign them to instance variables. Since structs are so frequently used to simply hold onto state/keep data around, it makes sense for the compiler to provide an initializer that takes the entire initial state/set of data. In other words: if you find yourself using such an initializer for a class (an initializer that merely assigns the arguments to instance variables), you probably want to make that class a struct.

> On Jun 22, 2017, at 9:38 AM, Bastiaan Marinus van de Weerd via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Strongly +1 on proposals #1 and #2. Cautiously +1 on #3 (I’m not sure about side effects there).
> 
> If #1 is already possible as Jon Shier says using an extension, I’d say it deserves promotion to be part of the language (e.g. Mike’s proposed `default init`), or at least should be made more discoverable (e.g. using a Fix-It on an implementation equivalent to the default initializer).
> 
> 
> –Bastiaan
> 
>> On Wed, Jun 21, 2017 at 8:00 PM, Jon Shier via swift-evolution <swift-evolution at swift.org> wrote:
>> 1 can already be accomplished by moving the custom initializer into an extension. 
>> 
>> 
>> Jon
>> 
>>> On Jun 21, 2017, at 7:42 PM, Mike Kluev via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> hi. here are a few somewhat related initializer proposals for your consideration.
>>> they are designed as "opt-ins" so shall not break existing code.
>>> 
>>> ***** proposal 1 *****
>>> have an ability to keep default initializers in structs
>>> 
>>> struct S {
>>>     var int: Int
>>>     var float: Float
>>>     var bool: Bool
>>> }
>>> 
>>> here default initializer is currently generated:
>>> 
>>> struct S {
>>>     var int: Int
>>>     var float: Float
>>>     var bool: Bool
>>>     
>>> //  autogenerated:
>>> //  init(int: Int, float: Float, bool: Bool) {
>>> //      self.int = int
>>> //      self.float = float
>>> //      self.bool = bool
>>> //  }
>>> }
>>> 
>>> so we can write:
>>> 
>>> let s = S(int: 0, float: 0, bool: false)
>>> 
>>> so far so good. now i want to add a "convenience" initializer. i don't want the default initializer to go away though:
>>> 
>>> struct S {
>>>     var int: Int
>>>     var float: Float
>>>     var bool: Bool
>>>     
>>>     /* convenience */ init(x: Int) {
>>>         self.init(int: 0, float: 0, bool: false) // *** ERROR. this initializer is gone
>>>     }
>>> }
>>> 
>>> let s = S(x: 0)
>>> let s = S(int: 0, float: 0, bool: false) // *** ERROR. this initializer is gone
>>> 
>>> this may be convenient in some cases but not others.
>>> proposal: introduce an opt-in construct to keep the default initializer intact:
>>> 
>>> struct S {
>>>     var int: Int
>>>     var float: Float
>>>     var bool: Bool
>>>     
>>>     default init // explicit opt-in. suggest a better name
>>>     
>>>     /* convenience */ init(x: Int) {
>>>         self.init(int: 0, float: 0, bool: false) // still ok
>>>     }
>>> }
>>> 
>>> let s = S(x: 0) // ok
>>> let s = S(int: 0, float: 0, bool: false) // still ok
>>> 
>>>     
>>> ***** proposal 2 *****
>>> have the default initializer to have default nil values for all optional parameters in structs
>>> 
>>> struct S {
>>>     var int: Int
>>>     var float: Float?
>>>     var bool: Bool
>>>     
>>> //  autogenerated:
>>> //  init(int: Int, float: Float? = nil, bool: Bool) {
>>> //      self.int = int
>>> //      self.float = float
>>> //      self.bool = bool
>>> //  }
>>> }
>>> 
>>> in the extreme case:
>>> 
>>> struct S5 {
>>>     var int: Int?
>>>     var float: Float?
>>>     var bool: Bool?
>>>     
>>> //  autogenerated:
>>> //  init(int: Int? = nil, float: Float? = nil, bool: Bool? = nil) {
>>> //      self.int = int
>>> //      self.float = float
>>> //      self.bool = bool
>>> //  }
>>> }
>>> 
>>> usage:
>>> S(float: 3)
>>> S()
>>> S(int: 0, float: 0, bool: false)
>>> 
>>> note that this is still "opt-in" as the old code will be using the full form anyway and not break.
>>> 
>>> ***** proposal 3 *****
>>> introduce a similar opt-in default initialiser for classes:
>>> 
>>> class C {
>>>     var int: Int
>>>     var float: Float?
>>>     var bool: Bool
>>> }
>>> 
>>> let c = C(int: 0, float: 0, bool: false) // *** ERROR
>>> 
>>> class C {
>>>     var int: Int
>>>     var float: Float?
>>>     var bool: Bool
>>>     
>>>     default init // explicit opt-in. suggest a better name
>>>     
>>> //  this is autogenerated:
>>> //  init(int: Int, float: Float? = nil, bool: Bool) {
>>> //      self.int = int
>>> //      self.float = float
>>> //      self.bool = bool
>>> //  }
>>> }
>>> 
>>> let c = C(int: 0, bool: false) // ok
>>> 
>>> 
>>> ***** question 4 *****
>>> 
>>> this one is not a proposal, rather a question. probably there is a good reason for it, i just want to know it: why there is no default initializer for classes similar to what we have for structs?
>>> 
>>> 
>>> =================================
>>> thoughts and comments on any of these?
>>> 
>>> Mike
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170622/4287a61c/attachment.html>