Proposal: partial initialization before returning nil from an initializer

Felix_Cloutier1 · 2015-12-17T16:00:56.000Z

Hi all,

Initializers can now fail, but objects still need to be fully initialized before you can return `nil` from them. For instance:

  class Foo {
    let bar: Int
    init?(baz: Int) {
      guard baz < 100 else {
        return nil
      }
      self.bar = baz
    }
  }

This trivial example causes the following error: "all stored properties of a class instance must be initialized before returning nil from an initializer".

For integers, that's easy: you can simply set them to zero. However, sometimes, you'd want initialization to fail because the arguments you received don't allow you to properly initialize a member. In these cases, you have to make the fields Optionals (implicitly unwrapped or not) to overcome this.

I remember that Chris said that this is a temporary issue and that it would eventually be fixed. I'm starting this thread because I'd love to have this with or before Swift 3 and I'd like to see who thinks this is big enough of an issue to rival the proposals we already have.

Félix

keith-other · 2015-12-17T16:20:08.000Z

I believe this has already been fixed here:

github.com/apple/swift

DI: Add support for early return from designated initializers

committed 06:36AM - 14 Oct 15 UTC

slavapestov

+1033 -667

Fixes <rdar://problem/18216578>. Swift SVN r32678

···

On Thu, Dec 17, 2015 at 10:01 Félix Cloutier <swift-evolution@swift.org> wrote:

Hi all,

Initializers can now fail, but objects still need to be fully initialized
before you can return `nil` from them. For instance:

        class Foo {
                let bar: Int
                init?(baz: Int) {
                        guard baz < 100 else {
                                return nil
                        }
                        self.bar = baz
                }
        }

This trivial example causes the following error: "all stored properties of
a class instance must be initialized before returning nil from an
initializer".

For integers, that's easy: you can simply set them to zero. However,
sometimes, you'd want initialization to fail because the arguments you
received don't allow you to properly initialize a member. In these cases,
you have to make the fields Optionals (implicitly unwrapped or not) to
overcome this.

I remember that Chris said that this is a temporary issue and that it
would eventually be fixed. I'm starting this thread because I'd love to
have this with or before Swift 3 and I'd like to see who thinks this is big
enough of an issue to rival the proposals we already have.

Félix

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Kevin_Wooten · 2015-12-17T16:25:02.000Z

Bottom of that commit…

utils/buildbot-release-notes.txt

···

On Dec 17, 2015, at 9:23 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

Oh, sweet.

Is there a changelog anywhere? I really like LLVM's release notes and how they're updated during development.

Félix

Le 17 déc. 2015 à 11:20:08, Keith Smiley <keithbsmiley@gmail.com <mailto:keithbsmiley@gmail.com>> a écrit :

I believe this has already been fixed here: DI: Add support for early return from designated initializers · apple/swift@f524802 · GitHub
On Thu, Dec 17, 2015 at 10:01 Félix Cloutier <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

Initializers can now fail, but objects still need to be fully initialized before you can return `nil` from them. For instance:

        class Foo {
                let bar: Int
                init?(baz: Int) {
                        guard baz < 100 else {
                                return nil
                        }
                        self.bar = baz
                }
        }

This trivial example causes the following error: "all stored properties of a class instance must be initialized before returning nil from an initializer".

For integers, that's easy: you can simply set them to zero. However, sometimes, you'd want initialization to fail because the arguments you received don't allow you to properly initialize a member. In these cases, you have to make the fields Optionals (implicitly unwrapped or not) to overcome this.

I remember that Chris said that this is a temporary issue and that it would eventually be fixed. I'm starting this thread because I'd love to have this with or before Swift 3 and I'd like to see who thinks this is big enough of an issue to rival the proposals we already have.

Félix

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Kevin_Wooten · 2015-12-17T16:31:41.000Z

Apologies, looks like that exists no longer in relevant branches, just saw that it was updated to describe new support of initializers.

···

On Dec 17, 2015, at 9:25 AM, Kevin Wooten via swift-evolution <swift-evolution@swift.org> wrote:

Bottom of that commit…

utils/buildbot-release-notes.txt

On Dec 17, 2015, at 9:23 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Oh, sweet.

Is there a changelog anywhere? I really like LLVM's release notes and how they're updated during development.

Félix

Le 17 déc. 2015 à 11:20:08, Keith Smiley <keithbsmiley@gmail.com <mailto:keithbsmiley@gmail.com>> a écrit :

I believe this has already been fixed here: DI: Add support for early return from designated initializers · apple/swift@f524802 · GitHub
On Thu, Dec 17, 2015 at 10:01 Félix Cloutier <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

Initializers can now fail, but objects still need to be fully initialized before you can return `nil` from them. For instance:

        class Foo {
                let bar: Int
                init?(baz: Int) {
                        guard baz < 100 else {
                                return nil
                        }
                        self.bar = baz
                }
        }

This trivial example causes the following error: "all stored properties of a class instance must be initialized before returning nil from an initializer".

For integers, that's easy: you can simply set them to zero. However, sometimes, you'd want initialization to fail because the arguments you received don't allow you to properly initialize a member. In these cases, you have to make the fields Optionals (implicitly unwrapped or not) to overcome this.

I remember that Chris said that this is a temporary issue and that it would eventually be fixed. I'm starting this thread because I'd love to have this with or before Swift 3 and I'd like to see who thinks this is big enough of an issue to rival the proposals we already have.

Félix

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Felix_Cloutier1 · 2015-12-17T16:23:04.000Z

Oh, sweet.

Is there a changelog anywhere? I really like LLVM's release notes and how they're updated during development.

Félix

···

Le 17 déc. 2015 à 11:20:08, Keith Smiley <keithbsmiley@gmail.com> a écrit :

I believe this has already been fixed here: DI: Add support for early return from designated initializers · apple/swift@f524802 · GitHub
On Thu, Dec 17, 2015 at 10:01 Félix Cloutier <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi all,

Initializers can now fail, but objects still need to be fully initialized before you can return `nil` from them. For instance:

        class Foo {
                let bar: Int
                init?(baz: Int) {
                        guard baz < 100 else {
                                return nil
                        }
                        self.bar = baz
                }
        }

This trivial example causes the following error: "all stored properties of a class instance must be initialized before returning nil from an initializer".

For integers, that's easy: you can simply set them to zero. However, sometimes, you'd want initialization to fail because the arguments you received don't allow you to properly initialize a member. In these cases, you have to make the fields Optionals (implicitly unwrapped or not) to overcome this.

I remember that Chris said that this is a temporary issue and that it would eventually be fixed. I'm starting this thread because I'd love to have this with or before Swift 3 and I'd like to see who thinks this is big enough of an issue to rival the proposals we already have.

Félix

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

keith-other · 2015-12-17T16:40:12.000Z

It's currently the second bullet point in the CHANGELOG in the main repo

github.com

apple/swift/blob/main/CHANGELOG.md

# CHANGELOG

> **Note**\
> This is in reverse chronological order, so newer entries are added to the top.

## Swift 5.9.2

* [SE-0407][]:

  Member macros can specify a list of protocols via the `conformances` argument to the macro role. The macro implementation will be provided with those protocols that are listed but have not already been implemented by the type to which the member macro is attached, in the same manner as extension macros.

  ```swift
  @attached(member, conformances: Decodable, Encodable, names: named(init(from:), encode(to:)))
  @attached(extension, conformances: Decodable, Encodable, names: named(init(from:), encode(to:)))
  macro Codable() = #externalMacro(module: "MyMacros", type: "CodableMacro")
  ```

## Swift 5.9

### 2023-09-18 (Xcode 15.0)

This file has been truncated. show original

···

On Thu, Dec 17, 2015 at 10:32 Kevin Wooten via swift-evolution < swift-evolution@swift.org> wrote:

Apologies, looks like that exists no longer in relevant branches, just saw
that it was updated to describe new support of initializers.

On Dec 17, 2015, at 9:25 AM, Kevin Wooten via swift-evolution < > swift-evolution@swift.org> wrote:

Bottom of that commit…

utils/buildbot-release-notes.txt

On Dec 17, 2015, at 9:23 AM, Félix Cloutier via swift-evolution < > swift-evolution@swift.org> wrote:

Oh, sweet.

Is there a changelog anywhere? I really like LLVM's release notes and how
they're updated during development.

Félix

Le 17 déc. 2015 à 11:20:08, Keith Smiley <keithbsmiley@gmail.com> a écrit
:

I believe this has already been fixed here:
DI: Add support for early return from designated initializers · apple/swift@f524802 · GitHub
On Thu, Dec 17, 2015 at 10:01 Félix Cloutier <swift-evolution@swift.org> > wrote:

Hi all,

Initializers can now fail, but objects still need to be fully initialized
before you can return `nil` from them. For instance:

        class Foo {
                let bar: Int
                init?(baz: Int) {
                        guard baz < 100 else {
                                return nil
                        }
                        self.bar = baz
                }
        }

This trivial example causes the following error: "all stored properties
of a class instance must be initialized before returning nil from an
initializer".

For integers, that's easy: you can simply set them to zero. However,
sometimes, you'd want initialization to fail because the arguments you
received don't allow you to properly initialize a member. In these cases,
you have to make the fields Optionals (implicitly unwrapped or not) to
overcome this.

I remember that Chris said that this is a temporary issue and that it
would eventually be fixed. I'm starting this thread because I'd love to
have this with or before Swift 3 and I'd like to see who thinks this is big
enough of an issue to rival the proposals we already have.

Félix

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution