[swift-evolution] Nil-rejection operator

[Ben Cohen]

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 force-unwrapping, using !! for throwing not trapping doesn’t seem appropriate. 

I would rather see !! used for something slightly different, which is force-unwrap with an explanation. e.g. 

  someOptional !! “this should never be nil for reasons” 

would be equivalent to the expression:

  someOptional != nil ? someOptional! : fatalError(“this should never be nil for reasons”)  // not that this compiles but you get the idea

Justification being: force unwrap isn’t universally bad despite what you might hear sometimes, and can be read as a precondition that nil is impossible/unhandleable at this point in the code. But preconditions should usually be accompanied with an explanation to output when they fail, which postfix ! doesn’t allow for but infix !! would.


> On Feb 20, 2017, at 10:22 AM, Jack Newcombe via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <jack at newcombe.io <mailto:jack at newcombe.io>> wrote:
>> 
>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

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