Proposal: partial initialization before returning nil from an initializer

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

I believe this has already been fixed here:

···

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

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

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

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

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

···

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