[swift-evolution] Idea: Properties in Failable Initializers less verbose

Niels Andriesse andriesseniels at gmail.com
Tue Jul 25 16:13:22 CDT 2017


Although I have come across this problem as well (particularly when
initializing from JSON), I don't think the solution is to fundamentally
change initialization behavior like this, because 1. ) that is probably
going to break a good deal of existing code and 2. ) I think that the
introduction of the Codable protocol in Swift 4 will eliminate most cases
where this is really a problem.
On Wed, 26 Jul 2017 at 02:30 Taylor Swift via swift-evolution <
swift-evolution at swift.org> wrote:

> I’d be in favor of this.
>
> On Tue, Jul 25, 2017 at 5:44 AM, philohan95 via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I think the current way to initiate models in a Failable Initializer
>> `init?()` is overly verbose and should be shortened down so less
>> boilerplate should be needed.
>>
>> The current way:
>>
>> ```
>> let someProperty: Any
>> let anotherProperty: Any
>>
>> init?(data: [String: Any]) {
>>         guard
>>                 let someProperty = data["some_key"],
>>                 let anotherProperty = data["another_key"]
>>         else {
>>                 return nil
>>         }
>>
>>         self. someProperty = someProperty
>>         self. anotherProperty = anotherProperty
>> }
>> ```
>>
>> As you can see we had to use the properties twice (this would also be the
>> case of `if let`) making the initializer twice as long as necessary and
>> becomes a pain to implement when having more than 1 property.
>>
>> My idea is extending the power of the `guard` statement
>>
>> Idea:
>>         init?(data: [String: Any]) {
>>                 guard
>>                         someProperty = data["some_key"], // Currently
>> fails because `self` us used before all stored properties are initialized
>>                         anotherProperty = data["another_key"]
>>                 else {
>>                         return nil
>>                 }
>>         }
>> }
>>
>> _______________________________________________
>> 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/20170725/ccf7c248/attachment.html>


More information about the swift-evolution mailing list