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]> 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]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to