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

Makes sense. Off the top of my head, I can imagine the following two operators: `optional?^` throws some default error if nil `optional ??^ error` throws `error` if nil You could have optional throwing chaining as well — basically everywhere the language currently offers a choice of graceful

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

> On Jul 26, 2017, at 9:55 AM, Robert Bennett wrote: > > Is there a reason that a throwing unwrap function/operator isn’t part of the > standard library? Seems like it would be handy to be able to have a one-liner > for attempting to unwrap and throw if it’s nil. ?!

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

Is there a reason that a throwing unwrap function/operator isn’t part of the standard library? Seems like it would be handy to be able to have a one-liner for attempting to unwrap and throw if it’s nil. Something like postfix operator .?! extension Optional { static postfix func

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

> On Jul 25, 2017, at 2:44 AM, philohan95 via swift-evolution > 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:

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

+1. > On 25. Jul 2017, at 18:30, Taylor Swift via swift-evolution > wrote: > > I’d be in favor of this. > > On Tue, Jul 25, 2017 at 5:44 AM, philohan95 via swift-evolution > > wrote: > I think the

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

This was one of the issues I tried to address in my proposal about factory initializers (based on all previous discussions on that topic). I’d love to see this happen, but much like the reason why I didn’t push the factory initializers proposal to review, I think now’s not the time for this. The

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

This problem is not limited to JSON. I have scads of underscored variables and guard bindings in my code because of this limitation, though I rarely work with JSON. On Tue, Jul 25, 2017 at 5:13 PM, Niels Andriesse wrote: > Although I have come across this problem as

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

Catching and throwing exceptions is not the same as a controlled guard fail. It’s also quite verbose and requires extra types to be defined outside the scope of the initializer. On Tue, Jul 25, 2017 at 5:35 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Jul 25,

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

On Tue, Jul 25, 2017 at 4:44 AM, philohan95 via swift-evolution < swift-evolution@swift.org> wrote: > 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

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

I’ll take the opposite stance. Why limit this to initialization? I’d love to be able to guard assignments to *any* variable, whether it’s a property or not: func foo() { let bar: String if someCondition { guard bar = mightReturnOptional() else {

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

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

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

I’d be in favor of this. On Tue, Jul 25, 2017 at 5:44 AM, philohan95 via swift-evolution < swift-evolution@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. >

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

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