[swift-evolution] Nil-rejection operator

[Xiaodi Wu]

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 nil coalescing operator has problems of its own that have
been raised on this list, mostly to do with sometimes unintuitive behavior
as a result of its associativity and precedence.
On Wed, Feb 8, 2017 at 14:35 Jack Newcombe <jack at newcombe.io> wrote:

> 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> 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> 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
>
> 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
>
>
> _______________________________________________
> 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/20170208/295d09f7/attachment.html>