[swift-evolution] Nil-rejection operator

[Jack Newcombe]

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 <xiaodi.wu at gmail.com> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170208/bef4626c/attachment.html>