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 in the standard library. > On 8 Feb 2017, at 20:29, Xiaodi Wu <[email protected]> wrote: > > 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, 2017 at 14:20 Jean-Daniel via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > 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 >> <[email protected] <mailto:[email protected]>> a écrit : >> >> 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 >> operators (!, ?, ??). The outcomes of using these are as follows: >> >> - value? : >> if value is nil, do nothing and return nil >> if value is not nil, complete the chain by evaluating the rest of the >> expression. Return the result of the expression >> - value! : >> if value is nil, throw.a fatal error. >> If value is not nil, complete the chain by evaluating the rest of the >> expression. Return the result of the expression >> - value ?? default : >> if value is nil, return default >> if value is not nil, return value >> >> It seems to me that, if it is possible to coalesce a nil value with a >> default value, it should also be possible to reject a nil value a non-fatal >> error. >> >> 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 forced unwrapping >> of a variable, but with the provision of an error to throw in place of >> throwing a fatal error. >> >> - value !! Error : >> if value is nil, throw non-fatal error >> if value is not nil, return value >> >> Example of how this syntax might work (Where CustomError: Error): >> >> let value = try optionalValue !! CustomError.failure >> >> It is possible to implement this in Swift 3 with the following declaration: >> >> infix operator !! : NilCoalescingPrecedence >> >> func !!<UnwrappedType: Any, ErrorType: Error>(lhs: >> Optional<UnwrappedType>, rhs: ErrorType) throws -> UnwrappedType { >> guard let unwrappedValue = lhs else { >> throw rhs >> } >> return unwrappedValue >> } >> >> I’ve added further examples including composition with the nil-coalescence >> operator here: >> https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d >> <https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d> >> >> This would be particularly convenient in cases where a functions expects >> significant number of optional to contain non-nil values, without the need >> to repeat non-generic guard-let structures with the same else code-block. >> >> Best regards, >> >> Jack >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
