Re: [swift-evolution] Nil-rejection operator

> On Feb 20, 2017, at 10:22 AM, Jack Newcombe via swift-evolution > wrote: > > Hi all, > > Now that phase 2 has begun, am I able to submit a proposal for this? Hi Jack, Stage 2 has limited scope, proposals are on topic if they fit the criteria Ted laid out in his

Re: [swift-evolution] Nil-rejection operator

It doesn’t seem from reviewing the thread that there was much consensus regarding whether this is something that should be added or how it would be spelled, so probably needs more pitching before making it to a proposal. My own personal preference: Since ! is so strongly associated with

Re: [swift-evolution] Nil-rejection operator

Hi all, Now that phase 2 has begun, am I able to submit a proposal for this? Best regards, Jack > On 8 Feb 2017, at 20:00, Jack Newcombe wrote: > > Hi all, > > Currently there are a number of different operators for dealing with > optionals that cover most of the use

Re: [swift-evolution] Nil-rejection operator

I created this set of extensions so I could more easily deal with optionals in a context where I was already potentially throwing errors. extension Optional { func deoptionalize() throws -> Wrapped { switch self { case .some(let wrapped): return wrapped case

Re: [swift-evolution] Nil-rejection operator

On Thu, Feb 9, 2017 at 2:25 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I wonder if an alternative to the original proposal might be to allow > throw on the right hand side? So you could do: > > let y = x ?? throw myError > > You can do this today: extension Error {

Re: [swift-evolution] Nil-rejection operator

Two more tiny overloads is all takes to fix it: func ??(lhs: T?, rhs: T) -> T { if let lhs = lhs { return lhs } else { return rhs } } func ??(lhs: T?, rhs: U) -> Error { if let lhs = lhs { return lhs } else { return rhs } } > On Feb 9, 2017, at 12:01 PM, Jack Newcombe

Re: [swift-evolution] Nil-rejection operator

While this is nice, it adds ambiguity to the nil-coalescing operator. For example, when using nil-coalescing with a wrapped error value and an unwrapped error value as operands: let optionalError: Errors? = nil let result = optionalError ?? Errors.generic The above will result in an

Re: [swift-evolution] Nil-rejection operator

I think the best solution is overloading the existing ?? operator. It is very easy to do: func ??(lhs: T?, rhs: U) throws -> T { if let lhs = lhs { return lhs } else { throw rhs } } then you can say: do { let y = try x ?? myError } catch ... It might even

Re: [swift-evolution] Nil-rejection operator

This can actually be accomplished now using a closure: let value = optionalValue ?? { throw CustomError.failure }() However, this adds a layer of indirection that I’m not keen on and lacks the readability and maintainability of a well-defined operator. The problem with changing the

Re: [swift-evolution] Nil-rejection operator

> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution > wrote: > > I propose the introduction of a nil-rejection operator (represented here as > !!) as a complement to the above operators. > . > This operator should allow an equivalent behaviour to the

Re: [swift-evolution] Nil-rejection operator

As has been mentioned by the core team, syntactic sugar is not in scope for this phase of Swift 4 evolution and was said to be the lowest priority for the next. The bar for adding a new operator is going to be higher than for justifying the continued existence of an existing one. That said, the

Re: [swift-evolution] Nil-rejection operator

It’s absolutely true that this is syntactic sugar, but then so is nil-coalescing where "x ?? y” is syntactic sugar for “x != nil ? x : y”. You can also similarly recreate the nil-coalescing operator in Swift yourself, so I’m not sure that’s a strong argument for any operator being or not being

Re: [swift-evolution] Nil-rejection operator

I picked !! because it seemed to follow somewhat naturally from force-unwrap and nil-coalescing; however, that does depend on how you interpret the syntax of the operator. I interpreted ?? to figuratively mean “? with a default result instead of nil”, and so derived !! As figuratively meaning

Re: [swift-evolution] Nil-rejection operator

This seems to boil down to sugar where `guard let foo = ... else { throw ... }` is spelled `let foo = try ... !! ...`. While the analysis is interesting I don't see that this is an obvious win sufficient for the standard library. As you show it's possible to create for yourself. On Wed, Feb 8,

Re: [swift-evolution] Nil-rejection operator

While I find the concept interesting, I give a big -1 for using the ‘!’ operator for something else that fatal error. > Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution > a écrit : > > Hi all, > > Currently there are a number of different operators for

[swift-evolution] Nil-rejection operator

Hi all, Currently there are a number of different operators for dealing with optionals that cover most of the use cases. However, I think I’ve identified a missing complement for the existing operators for optionals. Take the following outcomes for interacting with an optional using existing