[swift-evolution] Proposal: partial initialization before returning nil from an initializer

Kevin Wooten kdubb at me.com
Thu Dec 17 10:31:41 CST 2015


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 at 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 at swift.org <mailto:swift-evolution at 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 at gmail.com <mailto:keithbsmiley at gmail.com>> a écrit :
>>> 
>>> I believe this has already been fixed here: https://github.com/apple/swift/commit/f524802e129f17de16fa6f8c3f08e5bcf75cc581 <https://github.com/apple/swift/commit/f524802e129f17de16fa6f8c3f08e5bcf75cc581>
>>> On Thu, Dec 17, 2015 at 10:01 Félix Cloutier <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20151217/5ab13be1/attachment.html>


More information about the swift-evolution mailing list