[swift-evolution] a few initializer proposals

[Bastiaan Marinus van de Weerd]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170622/3c9fd29a/attachment.html>